Продукт vs проект, и в чем разница для разработчика.
Представим проект по постройке дома на заказ. Есть чертежи, есть план работ, сроки. Всё посчитано, всё оптимально. Берешь ресурсы, делаешь по плану, в срок сдаешь дом. Звучит просто.
На деле все проекты едут по срокам, а дом в итоге получается не совсем таким, как его задумывали. И когда дом сдадут, внезапно окажется, что по соседству построили дом для сдачи в аренду посуточно, и там каждый вечер тусовки. Это я веду к тому, что за время проекта может произойти столько всего, что по итогу результат проекта может быть уже никому не нужен.
В продуктовом подходе сначала быстро делают бытовку и в ней сразу начинают жить. Потом, если оказывается что жить здесь можно, бытовку начинают перестраивать. В новой версии учитывают специфику местности. Например, добавляют теплоизоляцию и отопление. И так итерациями улучшают, делая более подходящим под изменяющиеся условия. Если рядом построили дом с вечеринками, можно добавить нашему дому шумоизоляции в новой версии.
Что это значит для разработчика?
В проекте есть начало и конец. Обычно стараются пилить проект одной командой от начала и до конца. Редко донабирают разрабов в середине. Это значит, что в большинстве случаев это green field, возможность начать с нуля, спроектировать красивую архитектуру и заложить инженерные практики, которые сберегут время в конце проекта, когда сроки будут гореть. Ну а если что-то не совсем правильно спроектировали, то часто выбирают вариант не переделывать, а довести проект до конца и переключиться на следующий.
В продукт постоянно приходят новые разработчики и уходят старые. Ротация кадров для продукта — нормальное явление. Приходя в продукт, надо быть готовым иметь дело с легаси. Потому что оно приносит деньги. И нужно уметь дорабатывать легаси и строить рядом с ним новые направления. И при построении чего-то нового нужно уметь заложить архитектуру и инженерные практики такие, чтобы не испытывать проблем, когда это станет легаси. У продукта нет конца как у проекта, поэтому разработчики имеют дело со своим же легаси через год-два-пять.
Поэтому в продукте так важно «правило бойскаута»:
Представим проект по постройке дома на заказ. Есть чертежи, есть план работ, сроки. Всё посчитано, всё оптимально. Берешь ресурсы, делаешь по плану, в срок сдаешь дом. Звучит просто.
На деле все проекты едут по срокам, а дом в итоге получается не совсем таким, как его задумывали. И когда дом сдадут, внезапно окажется, что по соседству построили дом для сдачи в аренду посуточно, и там каждый вечер тусовки. Это я веду к тому, что за время проекта может произойти столько всего, что по итогу результат проекта может быть уже никому не нужен.
В продуктовом подходе сначала быстро делают бытовку и в ней сразу начинают жить. Потом, если оказывается что жить здесь можно, бытовку начинают перестраивать. В новой версии учитывают специфику местности. Например, добавляют теплоизоляцию и отопление. И так итерациями улучшают, делая более подходящим под изменяющиеся условия. Если рядом построили дом с вечеринками, можно добавить нашему дому шумоизоляции в новой версии.
Что это значит для разработчика?
В проекте есть начало и конец. Обычно стараются пилить проект одной командой от начала и до конца. Редко донабирают разрабов в середине. Это значит, что в большинстве случаев это green field, возможность начать с нуля, спроектировать красивую архитектуру и заложить инженерные практики, которые сберегут время в конце проекта, когда сроки будут гореть. Ну а если что-то не совсем правильно спроектировали, то часто выбирают вариант не переделывать, а довести проект до конца и переключиться на следующий.
В продукт постоянно приходят новые разработчики и уходят старые. Ротация кадров для продукта — нормальное явление. Приходя в продукт, надо быть готовым иметь дело с легаси. Потому что оно приносит деньги. И нужно уметь дорабатывать легаси и строить рядом с ним новые направления. И при построении чего-то нового нужно уметь заложить архитектуру и инженерные практики такие, чтобы не испытывать проблем, когда это станет легаси. У продукта нет конца как у проекта, поэтому разработчики имеют дело со своим же легаси через год-два-пять.
Поэтому в продукте так важно «правило бойскаута»:
«оставь место стоянки чище, чем оно было до твоего прихода». Чистка не обязательно должна быть глобальной, достаточно почистить хотя бы небольшой кусок кода, режущий глаз.
© Роберт Мартин