Зачем Илон Маск Твиттер распечатал, или как бизнесу перестать быть заложником IT

Мне очень повезло, что я был за рулем, в этот гнусный октябрьский день. Так бы пошел водку пить. А так — вполне себе ничего: едешь, куда глаза глядят, рефлексируешь, и материшься: “за что же мне, хорошему, такая жопа”?

Начиналось буднично. Моя компания вот уже 20 лет занимается разработкой программного обеспечения на заказ. Входим в верхние строчки в рейтингах, отличный список клиентов, отлаженные процессы, делаем технически-сложные проекты (интеграции, личные кабинеты). У меня – спортивные самолеты на выходных…

Мне стало скучно, и я решил разработать собственный продукт с планами на мировой рынок. О планировании личного времени и задач я знал, наверное, вообще всё. Все книги, лайфхаки, методологии. И ни один из планировщиков меня не устраивал. Я решил разработать собственный, с блэкджеком и балеринами. В общем, кроме основной, стабильной работы — получить атмосферу амбициозного стартапа на дошираке.

Вот с этим проектом и возникла загвоздка. Выделенная, небольшая команда. Из которой за неделю у меня схантили двух разработчиков. На такие деньги, которые я просто не мог себе позволить. Никак. И ладно бы только одного — эта новость меня не сильно испугала. Уходил ключевой специалист. Технический лидер. Который знал проект от и до, принимал все ключевые технические решения.

Миллион долларов на разработку уже был потрачен. Первые пользователи потихоньку покупали платные подписки и ставили звездочки в сторах. Но это и близко не окупало затрат на команду.

И вот он руль. Дорога. И промозглый октябрь. И две мысли в голове: “Как ж я в это вляпался? Я же все знаю за IT” и “Чего ж теперь делать?”. Надо было разобраться.

Вы пробовали катить кубик? Чтобы это делать, нужно постоянно прикладывать усилия. С грани на грань, с грани на грань. Тупое, нудное занятие с невнятными перспективами. Хотя, если шлепнуть кубик по макушке, да под правильным углом — он сделает пару кульбитов сам. Но чаще — нет. С грани на грань, с грани на грань…

Другое дело — шарики. Катнул с достаточным усилием. И дальше он как-то сам. Долго. Если очень хочется, можно подопнуть для ускорения. Но в целом — гораздо веселее, чем кубик.

Заказная разработка (да и любая деятельность в сфере услуг) — это кубик. Каждый раз, с каждым клиентом нужно начинать заново. Считай, никакого масштабирования. Количество денег пропорционально переворотам кубика. Хочешь больше — не проблема. Херачь больше. Многие из нас этим и живут. Порой не плохо живут, кстати. Порой так себе. Но все мучаются. Вот как только подумаешь, что кубик тебе переворачивать до пенсии (ха-ха-ха, пенсия), тут то и подступает вселенская тоска.

Шарики забавнее. В мире программного обеспечения это сервисы и продукты, доступные по подписке. Потенциал роста бесконечный. А с какого-то момента можно заниматься только улучшениями. Мудрые IT-компании (вроде Яндекса) строят именно такие системы. Даже, неряшливый певец или писатель, или угрюмый программист может шарик себе сделать. Если сильно повезет. А вот менеджер среднего звена — нет. Ну большинство нет, это уж точно.

Промежуточные выводы. Кубики катать привычнее, но шарики — забавнее.

Проблема с выбором между шариками и кубиками вот в чем: оказывая услуги (или разрабатывая программы на заказ) вы практически мгновенно увидите финансовый результат своих усилий. Сделал — заработал, повторил.

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

Зачем весь этот гарантированный геморрой при негарантированном результате, если можно в очередной раз перекатить кубик? Это выбор, между “хорошо сейчас — плохо потом” и “плохо сейчас, хорошо потом”. Где “плохо сейчас” — очевидно, а “хорошо потом” далеко не факт.

Как-то мне попалась статистика среднего времени работы IT-специалистов в международных компаниях. Microsoft, Google, Amazon и много кто еще. Так вот. Среднее время составляло два года. Не знаю, какова дисперсия, но ориентир четкий:

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

Черт возьми! Мои проблемы начались Just-in-time. Но у меня уже был готовый шарик. Оставалось только выбрать из двух сортов дерьма: продолжаем или сдаемся.

Мы разрабатываем сервис для планирования дел и задач – SingularityApp. В нём собрали лучшие практики – управление временем, GTD, джедайские техники Максима Дорофеева и хаос-менеджмент. Всё это с удобным интерфейсом, приложениями для основных платформ, web-версией и кучей разных фишек.

Почему именно планировщик? Там же гиганты, типа Todoist, с давно сложившимися комьюнити и тысячи проектов, не справившихся с конкуренцией. Это ниша, где надо набрать десятки тысяч пользователей, чтобы банально выйти в операционный ноль.

Все началось со случайного разговора. Как-то, на одной конференции мы разговорились с генеральным директором 1С-Битрикс, Сергеем Рыжиковым. Он обронил фразу: “Не бойся лезть на рынки с большой конкуренцией. Лучше откусить 10% от большого пирога, чем 99 от маленького”. Примерно так.

Потом я читал Тимоти Ферриса. Эта устаревшая и довольно вредная книга, как работать по 4 часа в месяц (или типа того). На самом деле — никак. Из нее меня зацепила одна мысль: “Никаких услуг! Только продукт. Который будет довольно дешевым, скажем $20”.

Что это может быть? Из того, в чем я более-менее разбираюсь это или управление временем (к тому времени я попробовал все планировщики), или что-то про авиацию, или про управление digital-проектами.

По управлению проектами мы сняли курс, который долгое время хорошо продавался, позже – я выпустил книгу. Ну а управление своими задачами — всегда мне нравилось и приносило пользу. Поэтому вот!

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

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

Ровно так я и поступил: посчитал и прикинул, сколько времени, сил и денег я готов потратить еще, не видя отдачи. Прописал это. Поставил точку отсечения и заранее принял возможные потери.

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

Промежуточные выводы: выставление стоп-лосса при принятии решений дает силу безразличия.

Следующие выходные я провел в офисе, в тишине, составляя факт-карту. Обычно, для решения проблем, я использую подход теории ограничений Голдратта (деревья текущей реальности) или тойотовский A3-анализ. Но в данном случае решил попробовать Курпатовский подход — он менее строгий.

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

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

Тут же встретился с руководителем проекта. Показал схему. Обсудили, как донести новости до команды и вообще какой план действий. Нашли пару слабых мест. Устранили. В общем, подготовились к черному понедельнику как могли. Спалось плохо.

Промежуточные выводы. Используйте формальные техники, вроде ТОС или факт-карт, чтобы посмотреть на ситуацию со стороны.

В понедельник начались откровенные разговоры. Я боялся, как ребята воспримут новости. Будут ли они переживать. Не будет ли лавины увольнений.

Мы собирались втроем — я, руководитель проекта + приглашали кого-то из оставшейся команды. Рассказывали ситуацию. Подробно зачитывали, какие проблемы есть и какие шаги можно предпринять.

И я охренел.

Оказывается, проблемы, которые изводят руководителя, командой воспринимаются гораздо спокойнее. Это ты ночами не спишь, думаешь “А что делать?”, “А как они воспримут?” Там же все гораздо спокойнее. Никто никуда убегать с корабля вслед не собирался. Сто процентов людей были готовы продолжать работу и решать возникшие трудности.

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

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

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

“Всё, блин, делается слишком медленно!” — именно такое чувство не покидало меня по ходу проекта. Я вообще-то программист по образованию и хорошо понимаю сложности, с которыми сталкиваются разработчики больших проектов. Но в этом проекте мне не хотелось вникать во все нюансы разработки. Я, типа, “инвестор”. И раз уж есть руководитель проекта, есть технический лидер – пусть они и занимаются этим. Каждый должен же свое дело делать, правильно?

Это была большая ошибка. Или банальная лень врубаться в детали. А оно так и происходит. Сначала ты ленишься врубаться в новое. А потом — перестаешь врубаться. Тут то всему и крышка.

По мере роста и развития проекта его архитектура обрастала, скажем так, странными решениями. Костылями и велосипедами.

Признаки плохого кода появлялись давно:

1. Сами ребята жаловались, что тот или иной компонент системы написан плохо. И надо всё переписывать. Самое плохое, что те же жалобы повторялись и после переписывания. А сами переделки занимали вечность. Две вечности.
   
2. Добавление в проект высококлассного сеньора кончилось тем, что сеньор сбежал из проекта через полгода с комментарием “Всё слишком сложно”.
   
3. Части проекта были написаны в разных стилях.
   
4. Скорость разработки не увеличивалась. Только замедлялась.
   
5. Много нытья. Слишком много.
   

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

Промежуточные выводы: задавай себе хотя бы раз в неделю вопрос: “Что я стараюсь не замечать?”. Вникай в детали. Учись.

Итак, я с головой залез внутрь проекта. По прошествию времени я не могу выделить какое-то одно действие, которое бы можно было отметить как “серебряную пулю”. Действий пришлось делать много. Придумать, сделать, проверить результат. Повторить.

Перво-наперво мы починили HADI-циклы (с.м. картику).. Каждую неделю по понедельникам, утром, работали по маркетинговому плану. Придумывали новые гипотезы. И проверяли итоги — аналитику, метрики, телеметрию. В общем, восстановили классический цикл Деминга в маркетинге.

Часть гипотез шла в разработку. Часть — в работу по продвижению или подготовку контента.

Вскоре мы поняли, что на текущей стадии развития проекта SCRUM работает слишком медленно. Он хорошо себя показал при разработке первых версий приложения. Но на этапе продвижения нам нужно было меняться гораздо быстрее. Часть работ мы перевели на КАНБАН. Тестирование и выпуск новых версий перевели в режим эстетиста: как только появилась готовая функция, тестировщики тут же проверяют ее и как можно быстрее по цепочке отправляют в релиз.

Далее — была переработана в наглядные формы телеметрия и аналитика в приложении. Стали понятны узкие места: где у нас явные недоработки и где мы теряем пользователей. Были сформированы десятки гипотез, как исправить ситуацию. Часть из них можно было быстро протестировать, не привлекая (или почти не привлекая) разработчиков.

И наконец, мы стали регулярно проводить Cust-dev-интервью с реальными пользователями. Не могу сказать, что были какие-то сверх-откровения. Но несколько идей (или тех мест, где наше приложение доставляет боль) мы выявили.

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

Мы потратили много времени на Code Review (чтение и изучение текущего кода). Было забавно прочитать, что Илон Маск, после покупки Твиттера, оставшись без львиной доли команды, начал именно с этого. Причем, распечатав твиттер и привлекая к Review команду из Tesla. Видимо, тех людей, которым он мог доверять.

Промежуточные выводы: иногда надо просто сесть и во всём разобраться. А иногда надо просто херачить. Не боясь замараться или перетрудиться.

Было очевидно, что код desktop-приложения нуждается в рефакторинге. Но что именно и как менять — нужно было определиться. Мы составили схемы взаимодействия компонентов системы. На это потребовалось две недели. Стали очевидны переусложненные компоненты. Вернее, связи между ними.

Сам рефакторинг выполнялся постепенно, и мы делаем его до сих пор. Сборку и работу приложения получилось ускорить в несколько раз. Начала появляться документация. Кроме интеграционных тестов (имитирующих действия пользователя) отрефакторенный код покрывался быстрыми юнит-тестами. Весь новый код проходил строгое ревью и документировался.

Отдельно шла работа по стандартизации кода. Мы выписывали в отдельный файл “странные” решения, найденные внутри системы. Дескать, вот тут странный кусок кода, и он бесит на 10 из 10. Обсуждали это всей командой. Постепенно стал понятен главный поставщик плохого кода — с ним мы распрощались; а раньше его жалели. Довольно быстро появилась нулевая терпимость к говнокоду. Что-то типа культа качества.

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

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

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

Это надо просто принять как “дано”. Их тоже понять можно: им постоянно надо навыки актуализировать, иначе через 5 лет никуда не возьмут, а после 40 — тем более. Но бизнесу от этого не легче.

В сущности, запуск проекта нужен только вам, бизнесу. Многим программистам достаточно просто пилить код, строя в нем Памятник Самому Себе. Так, чтобы другие программисты “офигели от того, какой он умный”.

При этом среднячкам (middle) нужен “суровый папка”. Такой, чтобы бил по рукам за кривые решения, хвалил за хорошие, и учил, учил, учил делать хорошо.

Некоторые разработчики просят наставника в открытую. Некоторые просто имеют влажную мечту. Если коллектив программистов маленький, а сурового “папки” нету — памятники самому себе растут гораздо быстрее.

Дело совсем дрянь, если программист в коллективе один. Он становится Незаменимым, Чувство Собственной Важности разрастается до небес, работать его хрен заставишь, а спорить и выносить мозг он готов часами. Даже с генеральным.

Есть еще более мерзкое явление: JSDD (Job Safety Driven Development). Работать так, чтобы не уволили. Усложнить всю систему настолько, чтобы только один единственный Незаменимый был в силах во всем разобраться. Например, есть две кладовщицы. У одной на складе полный порядок. У второй — так всё запутано, что только она знает, где что лежит. Какую уволят первой?

Заумь и переусложнение — то, с чем приходится постоянно бороться. Писать простой для понимания код и делать ясную архитектуру на порядок сложнее.

Рецепты от этого давно известны — нужно держать всю разработку в строгом порядке и регулярно проводить инспекции всего. Применять SCRUM, регулярно проводить Code Review. Создавать продукт как можно быстрее и регулярно выпускать новые версии. Собирать обратную связь от пользователей, отслеживать метрики, вроде Time To Market (время от момента идеи, до поставки решения на рынок). Делать документацию, покрывать систему тестами. Однако всё это чертовски дорого и не ускоряет разработку в краткосрочной перспективе. А бизнесу, часто, нужно здесь и сейчас.

Итак, плохие новости.

Как быть? По большому счету сейчас скрытая конкуренция идет именно на уровне технологии и автоматизации. Кто быстрее и лучше сможет автоматизировать максимум рутины — тот и молодец.

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

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

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

Этот вопрос я подробно разбирал в “Настольной книге project-менеджера”, издательства Бомбора. Здесь ограничимся краткими выводами.

Итак, если у вас разовый проект, рваная, нестабильная нагрузка, или нужно выпустить продукт (или MVP), но нет времени, сил, компетенций и желания возиться и “пасти котов” — однозначно, заказная разработка — правильное решение.

Если у вас идет стабильное развитие разработанного решения, если у вас планы на год-два вперед, причем, нужно часов 200-400 в месяц — скорее всего, в агентстве под вас будет выделенная команда. Внутри нее могут быть некоторые ротации (про средний срок работы сотрудников в IT мы говорили выше). Но это не ваша проблема.

Наконец. Если весь бизнес строится вокруг программного продукта, в месяц у вас стабильно задач на тысячу и более часов, а компетенций и энергии для построения внутренней команды хватает, то, скорее всего, своя команда — это ваш вариант.

Мне пришлось очень глубоко нырнуть в проект. Так глубоко, как на старте я не планировал. Пришлось вспомнить, как писать код. Разобраться во всех деталях системы. Изучить на практике современные технологии разработки. Спроектировать целевую архитектуру. Регулярно отслеживать изменения. Показывть, как правильно, и как не правильно. В общем добавить ясности. Почти по Сунь-Цзы:

Погружение в код и работу руками я воспринял сначала как деградацию. Мол, не справился как управленец, пошел за подчиненных работу делать. Отстой, фу-фу-фу! Это расстраивало, но было настолько интересно, что я решил: “Да ну нафиг!”. Работа над продуктом стала практически хобби. Появилось желание тратить все свободное время (его правда было не много) на разгребание самых сложных авгиевых конюшен в коде.

Работа руками дала два очень неожиданных эффекта:

1. Да хоть все увольняйтесь! Появилась уверенность, что даже если ситуация повторится, я к этому абсолютно готов. Я смогу ввести в курс дела новых людей. И обеспечить качество их работы. В крайнем случае — всегда смогу разобраться в любом аспекте сам. Причем — быстро.
   
2. Запасной аэродром. Что бы не случилось, у меня есть актуальные знания, опыт и практика в актуальной профессии и технологиях (исхожу из того, что вряд ли IT станет не актуален). Эти знания, конечно, вряд ли потребуются. Но в случае чего — они есть. И мозги стали шустрее работать. Двойная выгода. А то заржавеешь тут на управленческой работе.
   

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

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

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

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

Рутина или развитие — что же выбрать?

Интересная аналогия — передовой отряд и обоз. Обоз — это то, что имеет ресурсы. Но двигается медленно. И если армия его надолго оставит, уйдет далеко вперед — на обоз могут напасть, а кто-то разбредётся. Высок риск потерять обоз, слишком удаляясь от него.

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

Рабочая стратегия — уходить от обоза, ненадолго. Изучать территорию. И возвращаться. Направляя обоз по изученному уже маршруту.

Примерно так же нужно поступать с Рутиной и Развитием. Выделяйте время в своём графике, когда вы занимаетесь только развитием. Затем возвращайтесь к команде. И продвигайте ее до того уровня, куда успели забраться сами.

Промежуточные выводы: выделяйте время на развитие. И затем возвращайтесь к рутине. Рутина — первостепеннее.

Чем же в конце концов кончился этот кризис в мерзком, дождливом октябре 2021?

Дело было так.

После введения метрик и телеметрии, проведения cust-dev-интервью, стали очевидны несколько точек, где мы неправильно работаем с пользователями. Потребовалось не так много усилий, чтобы исправить это. И уже в декабре мы впервые вышли на прибыль. Пусть и небольшую. Пусть команда (а это основные расходы в IT) была несколько меньше. Но это было уже хорошо.

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

А дальше?

Итак. В декабре мы получили первую прибыль. То же повторилось в январе. И в феврале 2022 было очень похоже, что мы все делаем правильно. Ровно до 24го.

За один день мы потеряли 25% аудитории. Довольно существенным сегментом у нас была Украина. Затем нам запретили рекламироваться на западные рынки. Выводить деньги со сторов стало значительно сложнее. А российские пользователи не смогли оплачивать подписку через AppStore и Google Play.

А дальше??

Сложности с платежами — с одной стороны это было плохо. С другой стороны — у конкурентов (в основом, западных) для российского сегмента была такая же ситуация. Но им было пофиг на российский рынок. А нам нет. Естественно, мы предусмотрели альтернативные варианты оплаты, миграции данных от конкурирующий платформ. Добавились в российские сторы, реестры и т.д. В общем, сделали всё, что нужно, не щёлкая клювом. Рассматривались все варианты, пожалуй, кроме миграции команды.

А дальше???

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

А дальше????

Сейчас мы растем по пользователям и деньгам больше чем в два раза в год.

А дальше????!

Я не знаю, что будет дальше. Не знаю, как сложится рынок. Не знаю, какие испытания нас ждут. Но время крайне интересное. Задачи — интересные. Планов у нас — миллион. И есть силы их реализовать. В общем, я намерен досмотреть это шоу до конца.

Довольно сложно давать конкретные советы, не зная компании, её культуры, проекта и его архитектуры. Однако, если вы плотно работаете с IT, или решили строить in-house команду, — эти идеи и принципы вам помогут:

1. Время от времени задавайте себе вопрос: “Что я стараюсь не замечать?”. Не пропускайте слабые сигналы.
   
2. Вы будете чувствовать себя гораздо спокойнее в любом кризисе, если будете способны не только руководить. Но и делать что-то ценное своими руками. Особенно в вечно-востребованных сферах (строительство, медицина, IT :)). Не обязательно делать работу за подчиненных. Но важно быть способным. Оставьте себе такой запасной аэродром.
   
3. Стройте команды. Не один программист, а минимум — два. На любом участке. Иначе есть риск остаться с неподдерживаемым кодом. Дублируйте критически-важные знания.
   
4. Время от времени проводите ревью проекта кем-то со стороны. Если хватает сил и компетенций (оптимально) — проводите ревью самостоятельно. Илон Маск — не брезговал 🙂
   
5. Стандартизируйте качество. Используйте чек лист и автоматизированные проверки, чтобы убедиться, что стандарты не нарушены. Регулярно обсуждайте повышение качества. В долгосрочной перспективе есть прямая зависимость между качеством продукта и трудоемкостью. Качественный продукт поддерживать и изменять дешевле и проще.
   
6. Создавая команды поставьте сильного Руководителя Проекта. Лучше с агентским опытом. Ещё лучше — с сочетанием технического бэкграунда и хорошими переговорными навыками. Все крутится вокруг этих двух компетенций. Знания в маркетинге будут плюсом.
   
7. Выбирая между двумя Руководителями Проектов, берите самого позитивного и энергичного. Никакие процессы не заменят энергию и драйв. Унылый Руководитель Проекта гарантированно сделает унылой всю команду и унылый продукт.
   
8. Поддержите его властью. Руководитель Проекта не должен быть мальчиком для битья, а должен иметь право формировать команду. Кроме того, у него должен быть доступ к ресурсу, открывающему любые двери внутри компании. Иначе проект забуксует во внутренней бюрократии. Итак, Руководитель Проекта должен иметь доступ к полю власти и поддержку со стороны высшего руководства.
   
9. Первую версию продукта или большую автономную разработку лучше отдать агентству. Так будет быстрее. Когда проект начнет вызревать (достигнет какой-то стабильной точки) — можно начать формировать свою команду.
   
10. Используйте классический SCRUM или Канбан для организации разработки. Не изобретайте колесо. Проводите стендапы. Демонстрации. Планинги. Обсуждайте задачи. Команда должна чувствовать свою причастность к важному.
    
11. Используйте тикет-системы. Снижайте до минимума СРОЧНО-ВАЖНЫЕ задачи в мозг.
    
12. Проводите ретроспективы. Следите за удовлетворенностью команды. Прислушивайтесь и решайте проблемы.
    
13. Подбадривайте. Хвалите больше и чаще. Общий тон настроений в коллективе должен быть мажорный.
    
14. Фокусируйтесь. Минимизируйте переключения команды. Дерготня, суета, спешка приводят к ошибкам и выгораниям.
    
15. Заведите и отслеживайте несколько простых метрик, говорящих об успехе команды. Визуализируйте эти метрики. Это могут быть оценки задачи в Story Point, которые вы отгрузили за очередной спринт (план-факт) и количество дефектов. Трех таких метрик (план, факт, дефекты) уже достаточно.
    
16. Решайте проблемы команды. Медленное железо, слабые сервера, неудобные стулья или необходимость отгулов — за этим всем нужно следить.
    
17. Проводите раз в полгода стратегические сессии с участием всей команды и заинтересованных в проекте лиц. Формируйте планы. Прозрачные и понятные для команды. Должна быть ясность целей и ясность пути.
    
18. Ищите вызовы и интересные задачи. Давайте время на изучение новых технологий. Работа не должна превращаться в рутину.
    
19. На зрелых проектах документируйте и стандартизируйте разработку. Покрывайте проекты автотестами. Это может быть дорого на старте. Но поможет избежать регрессий и повторения ошибок при развитии проекта.
    
20. Имейте в виду, что согласно статистике, рано или поздно у вас из команды будут отваливаться люди. И приходить новые. Это неизбежно, что бы вы ни делали. У вас, по сути, есть два года, чтобы раскрыть потенциал человека. Если всё сделаете грамотно — то больше, но редко.
21. Постройте процесс онбординга (погружения новых людей в команду). Избавляйтесь от токсичных людей, которые тормозят команду.
    Постройте карьерный трек по каждому члену команды. Проводите аттестации. Внедрите карты компетенций. Давайте время на учебу. Внедрите OKR.
    
22. Сами много читайте и развивайтесь. Пока есть развитие — не будет застоя. Обязательно почитайте старые книги Макаренко (например, «Педагогическая поэма»).
    
23. Снижайте персонало-зависимость. Стремитесь к совместному владению кодом. Не должно быть укромных уголков.
    
24. Делайте хороший продукт для хороших целей. Не тратьте время на разработку ерунды, от которой всех воротит.
    
25. Всё будет хорошо. Даже если — не будет!