Что заставило меня написать данный пост - очевидно. Задержка обещанного релиза модуля видео.   Это с нами происходит  не первый, да и явно  не последний раз. Но случается такое не только с нашей компанией и сервисом, явление это более чем частое. Вопрос  таких задержек актуален не только для крупных компаний, но и для стартапов,  даже для не очень больших.
И мне захотелось об этом немного порассуждать. Безусловно, около этой темы написано множество  и можно написать еще не одну книгу по управлению проектами, планированию и тайменджементу. Но формат блога предполагает более сжатое изложение вещей. Так что к сути.





Де факто, история знает огромное число примеров, когда релизы откладывались, например, на пол года, перенос выпуска Mac OS X 10.5, или в последний момент отложенный на 3 недели релиз Windows Vista из-за найденный ошибок в RC2.
Есть и более яркие примеры, Diablo 3, которая вышла на 2 года позже ожидаемого или Duke Nukem Forever, которая в принципе на 12 лет припозднилась от первоначальных заявлений. Ну и, конечно, выпустили уже далеко не то, что сначала затевалось.

То, что затягивать запланированное плохо для бизнеса - очевидно. Но что происходит, если имеет место неоправданная спешка?

В нашей истории был такой весьма показательный случай, который наши старые пользователи могут легко вспомнить. О-да, это то самое глобальное обновление в 2009 году. Стартовали мы с бодрых заявлений, что займет оно не более одной ночи и на утро система поднимется, как прекрасная принцесса от поцелуя принца. Но не тут то было :) Все затянулось аж на трое суток и добавило не мало седин  - как нам, так и нашим пользователям. А начиналось все в общем с наших обещаний, что будет Обновление. Оно было много где анонсировано, и несколько раз переносилось, общественность жаждала обещанного и решили "упереться рогом” и сделать его к первому апреля. То есть пошли банально на принцип. Вместо того чтобы отложить еще на недельку и нормально все рассчитать и проверить.  В результате получилось так как оно получилось: несколько бессонных ночей, трое суток простоя, шквал негатива, и достаточное большое число разных багов, которые правились потом еще не один день по живому. К счастью, у сказки был хороший конец, но припоминали нам это и справедливо - не один год.

Доверие - штука до крайности нежная. Зарабатывается с трудом и годами, а потерять можно за пять секунд.  Что лучше  - выпустить полусырой продукт во время или "хорошо испеченный”, но с задержкой?
Если провести гастрономические параллели - плохо приготовленный кекс, даже если его потом посолить, посластить и разогреть в микроволновке - это совсем не то, что отличный кекс с пылу-жару. Даже если его подать гостям на три часа позже. Правда, если подать на следующий день, то и гостей уже не будет. Поэтому часто приходится идти на компромисс. Кексы можно бы и новые испечь, т.к. вышли неидеальные или корицей посыпать, которой дома нет, а бежать в магазин - это еще плюс пол часа как минимум. Так что, тут лучше без перфекционизма.

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

Для себя в процессе разработки мы сделали следующие выводы: стараемся не готовить больше какие-то мега обновления, куда войдет работа за годы, а выпускать новые фичи плавно, без остановок серверов и т.п. Ввели процедуру тестирования в том числе публичного. Еще банальная вещь к которой мы пришли - не выкатывать обновления перед выходными или в выходные дни. Это так же имеет свойство плохо заканчиваться, так как все люди и на выходных может легко в нужный момент или программиста не оказаться, или сисадмина. И плюс ко всему с сообществом, от которого приходят баги, может выйти, что работать некому.

Искренно надеюсь, нам удается соблюдать баланс между своевременно и безглючно, и те наши пользователи и клиенты, для которых мы реально и с радостью работаем, это понимают.