Продуктовая разработка, будучи противопоставленной разработке заказной, для меня имеет огромное множество плюсов. Тут и возможность полноценно погрузиться в задачу, и долго и вдумчиво итерация за итерацией совершенствовать и развивать проект, и непосредственное взаимодействие с конечными пользователями, и отсутствие внешнего прописанного в договоре срока, к которому так или иначе, хочешь не хочешь, пусть и ценой недоделок надо запустить проект. Прописанный срок регулярно приводит к гонкам, выкидыванию тестирования и отладки (да, срок и функционал прописан в договоре, а вот тесты... кто ж их кроме программеров видит), запуску откровенно сырого и нежизнеспособного продукта. Зачастую менеджеры творят просто чудеса в убеждении заказчика, что на самом-то деле всё работает.

Другой вопрос, что, как показывает практика, внутренним проектам зачастую не хватает таких сроков. То, что я наблюдал -- отстутствие сроков и контроля за ними, требований запустить описанный объем функционала с необходимым уровнем качества в заданную дату... приводит к расхолаживанию команды.

Оборотной стороной продуктовой разработки является постоянный поток текучки, латания дыр, взаимодействия с саппортом и т.д. Поток этот ведет себя как газ и постоянно заполняет ровно все предоставленное ему время. В тот момент, когда сроки пропадают, текучка заполняет всё: если нет конкретной даты, к которой надо сделать работу, её всегда можно отложить, можно заняться тем, что болит именно сейчас, можно сделать ту штуку, о которой просит та симпатичная девчушка из клиентской службы, пусть даже функция и не слишком-то нужна, да и уже есть пяток других способов добиться того же результата.

Следствием являются потеря фокуса и снижение скорости развития, команда погрязает в мелочах, вместо того, чтобы расходовать свои силы на что-то действительно важное. Это же приводит и к потере тонуса: когда ты изо дня в день чем-то занят, но по прошествии недели, месяца, года, тебе не на что показать и с гордостью сказать "это сделал я", это демотивирует. А затем расслабленность становится настолько привычной, что в случае необходимости уже не напрячься: отвыкли, разучились.

Я не говорю о том, что и здесь надо биться за запуск в срок любой ценой: если функционал откровенно сырой или ненужный, в чем смысл его запускать?! Но цель и срок должны быть, должны быть всегда, даже если позабыть про внешние факторы в духе уже назначенной даты старта проплаченной рекламной компании, прописанных в законодательстве сроков сдачи отчетности и т.д. и т.п. Да, я против навязанных сроков, но объем надо оценить, поставить дату и держаться за неё, держаться максимально точно. Это нужно всем. Да, и вам тоже.

Так сложилось, что в этом году, как это ни печально, не состоится Barcamp.lv. А жаль... Во многом жаль из-за того, что на этом баркампе я собирался выступить. Если вы читали недавние мои посты, то содержание доклада вряд ли будет неожиданным, но презентацию, как мне кажется, всё же стоит посмотреть:

Итак, первый раунд мы выиграли -- можем отодвинуть другие задачи и взяться за дело. Про технические особенности реализации я особо распинаться не буду -- существует множество доступных материалов.

У нас была очевидная цель -- получить быстрый результат, чтобы иметь карт-бланш на дальнейшие изменения. Что ж, мы взяли свободно распространяем минифаер, написанный на php, малость обработали его напильником, изменили способ показа баннеров у нас на сайте, внесли еще пару быстрых изменений. По дороге выяснилось, что как минимум в нашем случае minify падает, если ему разом скормить jQuery, jQuery UI и свои скрипты. Что ж, разнесли на 2 блока. Оценка сайта по Yslow выросла с 53 до 68. Не идеал, но для начала -- достаточно. Что же теперь? Как говорит Саша Орлов, "снес яйцо -- кудахтай". Итак, надо было показать, что внесены правильные изменения, что мы не зря потратили время, да и вообще молодцы.

Проблема в том, что просто сидеть и ждать результатов несколько... некорректно. Т.е. произошедшие после этого изменения можно списать на что угодно. Как известно "после не значит из-за". При этом не забудьте, что изменения могут быть как положительные, так и отрицательные, при этом совершенно не связанные с произведенными работами (скажем, начались праздники, и количество заказов упало).