Сделаем по-быстрому, потом переделаем по-нормальному

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

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

Спешка оправдана, когда вы опаздываете на поезд. Если он уходит в 10:00, то он уйдёт независимо от любых ваших усилий это предотвратить. Ну, кроме разве что если ваша девушка ляжет поперёк рельсов. В остальных случаях спешка в проектах – это простая незамысловатая ложь, которую вешают на уши доверчивым разработчикам, чтобы выжимать из них больше результата за меньшие деньги.

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

Выяснить, что реально делают конкуренты внутри себя, всегда достаточно сложно. Когда они распускают слухи о якобы начале разработки какого-то нового направления, обычно это значит что там на 90% всё сделано и идёт закрытое бета-тестирование. Говорить в этот момент, что мы сейчас начнём то же самое и успеем их опередить – абсурд.

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

В чём же тогда реальная причина спешки? Очень просто:

Большинство людей, открывающих собственный малый и средний бизнес, – люди эмоциональные. Эмоциональная подоплёка того, что они занимаются своим собственным делом, для них значит гораздо больше чем стратегия и тактика. А разработчики по определению живут логикой и алгоритмами. Они описывают алгоритмами свою жизнь и поведение, и для них естественно ожидать от остальных того же самого.

И как только слова руководителя, сказанные “сегодня”, логически никак не вяжутся с тем что тот же руководитель сказал “вчера” – у разработчиков в голове наступает мощный диссонанс и подавленность. Особенно если сказанное “сегодня” совершенно противоречит очевидному алгоритму планируемого будущего компании, который ещё “вчера” вроде как был расписан на несколько месяцев вперёд.

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

В чём же, чёрт побери, причина?

А причина проста: мотивы собственников компаний – собственнические. И когда на это накладываются эмоции – получается простое детское “хочу”. Вы ждёте от него проявления силы воли, логики, стратегии, анализа, делового предвидения – но это всё мишура. За мишурой скрывается обычный капризный ребёнок, который в магазине игрушек протягивает ручки к большому красному самосвалу и говорит “хочу, дай”. И как было бы в реальности в детском магазине – все объяснения папы о том, что денег в конце месяца банально не хватит на еду – разбиваются о детские слёзы на тему “папа, ты меня не любишь”..

Не пытайтесь объяснить такому руководителю, что спешка в проекте приведёт к проблемам в будущем. Человек, рассуждающий логически и стратегически, в таких объяснениях не нуждается. А эмоциональный большой ребёнок в конце месяца всё равно придёт на кухню и будет просить у папы и мамы полноценный завтрак, обед и ужин. И он никогда не признается, что реально виноват только он сам, получив себе большой красный самосвал.

Эмоционально неустойчивые руководители склонны классифицировать любую случайность как общеизвестную закономерность. Например, одна из веб-студий в которых я работал, делала подряд совершенно различные сайты – от строительных компаний до колхозных удобрений. И вот однажды, когда попался заказ на сайт банка, через некоторое время нам пришёл жесткий выговор за то, что мы не владеем терминологией фондов, инвестиций, акций, депозитов и т.д. – ведь (цитирую) “разработка сайтов для банков это же основное направление деятельности нашей компании”.

Виноваты всегда будете вы. Даже если вы пишете отчёты, предоставляете числовые метрики, показываете все цифры и расчёты, – их никто не будет читать. Всё равно в конечном итоге виноваты будете вы. Что не предотвратили, не убедили, не доказали.

Ни один из таких руководителей не признает, что в конечном провале проекта виноват он. Виноват в том, что нанял недостаточно людей, что сэкономил на ресурсах, что заставил работать “по-быстрому” в ущерб надёжности, что игнорировал расчёты и метрики. Просто в очередной критически момент, как в кинофильме “Матрица” – “избранный” тимлид узнает что до него по этому кругу прошло уже 6 таких же людей. Затем все грехи будут списаны на уволенного тимлида и ушедших с ним сотрудников, и с новой свежей командой круг начнётся заново. Это безотказная схема, ведь уверенность что “вот уже скоро” всё изменится к лучшему – самый лучший мотиватор для разработчиков.

Что с этим делать?

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

Во-вторых, можно это просто не принимать близко к сердцу. Как правило, история не помнит своих героев, и крайне маловероятно что если вы прогнётесь и будете писать код в спешке и без тестов – якобы всё мировое сообщество разработчиков потом будет показывать на вас пальцем. Нет. Например, не смотря на то, что моя текущая должность (техдиректор UMI.CMS) подразумевает некоторый статус и популярность, в реальности этого нет. Когда я представляюсь людям, то получаю ответ “ааа, мы что-то про вас слышали” только на менеджерских конференциях. Во всех остальных случаях даже тем людям, которые вроде как владеют не первым сайтом, приходится объяснять что дескать есть рынок CMS, на нём такие-то игроки, мы на нём занимаем стабильное второе место, а в таком-то рейтинге аж первое. Ну и после этого уже “хм, интересно, будем знать”.

Поэтому, особенно если вы не стоите на верхушке компании, а занимаете место среди менеджеров или “простых смертных” разработчиков – вы можете просто расслабиться и получать удовольствие от ежедневной смены курса. Единственное – вам будет стыдно смотреть в глаза своим коллегам и подчинённым.

И наконец в-третьих – с этим можно эффективно работать. Методики Agile придумали не дураки, и я откровенно подозреваю что их истинная подоплёка была в том чтобы надрессировать команду быстро менять курс не вследствие изменяющихся бизнес-требований (ну сами подумайте, схуяли им меняться каждую неделю?), а для более эффективной работы с эмоционально неустойчивыми заказчиками. Поэтому если вы преподносите руководителю Agile как эффективную стратегическую методику – вас ждёт полный провал. А если вы покажете, что готовы быстро метаться из стороны в сторону и решать “вот прямо сейчас важные” задачи – вас будут носить на руках.

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

По какому пути пойти – решать вам 🙂