Итак – волшебное слово «продукт». Любая компания, которая занимается разработкой программного обеспечения, мечтает иметь линейку продуктов. Какие-то более коммерчески успешны, какие-то менее. Какие-то продукты вообще разработаны для полноты портфеля или как утилизация свободных ресурсов разработчиков. Но всё упирается в слово «продукт». Мы разрабатываем «продукт», мы поддерживаем «продукт». Но что такое «продукт»?
Начинается всё с того что кроется под аббревиатурой MVP (minimum viable product). Минимальный жизнеспособный продукт. Я уже один раз подробно писал на эту тему. Повторюсь еще раз – когда я слышу эту аббревиатуру, я всегда пытаюсь представить «минимально жизнеспособного человека». Сразу приходит в голову создание без одной почки, с проблемами с головой, возможно коматозник. Но это человек и он жизнеспособен. А теперь представьте, что вас пытаются уговорить построить семейную жизнь с таким человеком. Звучит как бред? Но это не бред когда такую поделку вам пытаются продать как MVP «нового революционного продукта».
А может ли быть MVP вполне полноценным продуктом? Ну, в принципе да. Теоретически возможно. Но давайте будем реалистами. Для такого развития событий нужны следующие условия:
1) Наличие времени. Т.е. разработка в условии отсутствия цейтнота времени.
2) Собранная команда квалифицированных специалистов. Т.е. не собираемая, в процессе разработки, команда, а уже имеющаяся, сыгранная и лояльная, а не с наличием людей, собирающихся уволиться
3) Четкая постановка задачи на разработку продукта. Или гарантия того что не произойдет pivot.
Вроде хватит. Хотя по факту надо бы добавить еще группу продажников, которые нашу работу затем будут «впаривать» клиентам. Звучит просто, но на практике почти нереально. Будут выпадать один или более пунктов. И в результате разработка будет осуществляться на фоне кучи компромиссов. Начиная от «нанимаем кого попало, нам нужно код писать», до «да, баг есть. Выдаем с ним и потом поправим». Можно ли в таких условиях сделать надежный продукт? Сомневаюсь. А еще разработка будет осуществляться с подспудной мыслью о том, что мы живем в 21 веке и обновление продукта через интернет можно осуществить на раз/два. А значит, существование любого не смертельного бага не может препятствовать запуску продукта в промышленную эксплуатацию. Ведь баг можно «потом поправить».
К чему это еще приводит? Ну, поскольку спрос на программистов пока все еще выше фактического предложения – происходит перегрев рынка труда на фоне которого за низкокачественную работу можно вполне официально получать высокую зарплату. А поскольку работодателям это не может нравиться – запускаются еще пара процессов. Во-первых падает планка требований к кадрам и навык фактического умения писать код становится важнее чем фундаментальные знания, о чем я писал буквально только что. Во-вторых появляются курсы подготовки таких специалистов. Некоторые короткие в пару недель, некоторые более фундаментальные в полгода. Но всё это направлено на то чтобы сесть на 2 стула сразу – остудить рынок труда и слепить еще один маленький бизнесок по продаже образовательных курсов. Ведь работа программистов хорошо оплачивается. Вам же не скажут, что как только рынок насытится подобными «специалистами» - зарплаты полетят вниз.
Скажете, что я просто переживаю за своё место? Возможно. Но если у вас голова не застряла пониже спины – то наверное вы заметили что качество текущих приложений оставляет желать лучшего. Даже крупные игровые коробочные проекты выходят в промышленную эксплуатацию доверху наполненные багами. Так за что я сильнее переживаю? За своё место под солнцем или за то, что меня будут окружать поделки на коленке, пожирающие вычислительные ресурсы на моих устройствах?
Есть ли выход из ситуации? Разумеется. Он называется плановая экономика и социализм. Нам не нужно 100500 одинаковых игрушек, реализованных с целью выжимания денег из карманов игроков за счет нудного геймплея больше похожего на бесплатный труд. Нам не нужны десятки одинаковых B2B-продуктов, которые копипастят функционал друг друга и толкаются на рынке, который бы и не существовал без тех или иных требований федеральных законов. Ведь все эти ресурсы можно было бы потратить на что-то более полезное вместо копирования и реализации функционала, который выдается за конкурентное преимущество.