В прошлом своем посте я уже размышлял о проблеме MVP и торопливости в выводе продукта на рынок. Хочется эту мысль немножко развить.
Как я уже озвучивал – в самом термине ничего плохого нет. Идея очень здравая. Дать разработчикам понять минимальный функционал, который должен быть заложен в продукт при выходе на рынок. Пока не рассматриваем вопрос багов в данном функционале. Однако, смотря вокруг себя, и, примерно, анализируя как работают те или иные сервисы и программные продукты – я понимаю что проблемы и баги продукта вызваны не столько криворукостью разработчиков, сколько очень непродуманной архитектурой продукта, которая плохо поддается расширению и поддержке.
На первый взгляд кажется, что проблема в разработчиках. Они не продумали расширение и развитие функционала. Да это действительно так, не продумали. Только вот вспоминая свой опыт ведения продуктов с нуля – мне вспоминаются истории PIVOT-ов на пустом месте без обстоятельств. Т.е. просто в один прекрасный день руководство говорит, что хотели другой продукт, для другой целевой аудитории. Аналитик виноват? Да, виноват, неправильно поставил задачу. Только все поступившие постановки задач были согласованы с тем же руководством, что делает PIVOT.
Скажете, что разработчик должен работать строго по ТЗ? Да, должен. Только вот согласно гибким методологиям – в любой момент требования могут измениться, и не указано насколько.
Как эта связано с MVP? Да, в общем-то, напрямую. Разработчик, видя требования к продукту, не видит цели руководства и проектирует архитектуру под данные цели. Да, некая гибкость закладывается всегда, только вот ядро продукта строится на данном этапе. И если в требованиях написано «Сделать текстовый редактор», а в планах – IDE с симуляцией веб-серверов и возможность использования плагинов от третьей стороны – я могу прямо сейчас сказать, чем кончится дело.
Что бы я хотел как разработчик? Я бы хотел знать, что мы хотим получить в итоге. Какой продукт я делаю. В какую сторону планирует руководство его развивать. В противном случае – я буду из раза в раз делать одну и ту же работу поклейки ядра, хотя, как правило, очень многое можно было заложить заранее, зная курс развития. А попутно – буду править баги, так как, скорее всего, очень не многие изменения будут бесшовно класться на текущую архитектуру. Риск что-то сломать всегда велик.
Кто-то скажет, что просто я криворукий? Ну да, может быть, я не отрицаю. Только вот перед глазами у меня, не задумываясь, всплывает десяток онлайн-игр, которые запускались лишь бы запустить (см. MVP), а потом каждое обновление заканчивается портянкой багов, потому что изменения могли что-то сломать совсем в другой части системы
