Мой путь в управлении IT коллективами начался весьма внезапно, а именно в ситуации "А что если мы сделаем A, B, C и будем продавать этот продукт на рынок?" Забегая немного вперед, можно отметить что этот опыт не увенчался успехом. Но судя по всему мне удалось набить немало ценных шишек, чему-то научиться и, возможно, для кого-то это будет полезной статьей, чтобы количество таких шишек сократить.

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

Компания A. Когда все начиналось.

Как я уже упоминал выше, данная компания образовалась внезапно и нашей целью было не много, ни мало - а именно построить каркас для массовой интеграции моделей ML в энергопромышленность. На тот момент мы не знали ничего о планировании, о грамотном бюджетировании, не просчитывали риски и на соответствующие вопросы предполагаемых к сотрудничеству компаний отвечали непонимающим взглядом и мыслями "вы что, не понимаете, как сильно это может вам упростить жизнь?".

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

Компания В. Или первая работа по найму.

Формально в данную компанию я пришел уже (как я считал) с каким-то багажом знаний и именно с целью управлять IT коллективом. Стоит отметить, что на тот момент в компании было ровно так, как указано в заголовке статьи. У членов коллектива была какая-то цель и они как-то ей придерживались.

Я уже понимал про необходимость встреч и статусов; я уже знал про Jira и Confluence. Единственное, что я не понимал - это "зачем" это. Тем не менее мне не помешало начать внедрять это и стоит признать даже минимальная систематизация работы дает свои плоды. Но есть важный момент, что в IT коллективе существует очень тонкая грань между "ок, давайте вести таски" и "ок, вместо задач буду вести таски". Члены коллектива, которые делают классный и инновационный продукт - обычно хотят делать именно его, а не таски в Jira. Я утверждаю, что грамотный руководитель должен чувствовать это и балансировать между этими двумя состояниями не хуже канатоходца над водопадом Виктория. Да, безусловно нужны ежедневные митинги, недельное планирование и ретро встречи. Но если вы чувствуете, что ваши разработчики или аналитики вот-вот сделают то, к чему так долго стремились, а у вас в календаре ретро - перенесите.

Не менее важно начать выстраивать в компании процессы. Но что же такое процессы и зачем они нужны?

По моему убеждению процессы это то, что регламентирует жизнь коллектива и даже в случае, если вы (как создатель процесса) заболели, улетели или уволились - оно будет продолжать работать как швейцарские часы. К сожалению, без этого хаос настигает коллектив незаметно, как снежный ком. Разработчики хотят пробовать новые технологии, data science команды хотят воплощать в жизнь новые статьи. Хочется? Докажите, что это необходимо, покажите что от этого будет профит. Вам, как руководителю просто необходимо иметь ясную и задокументированную последовательность действий практически на любое "хочу" или "зачем". Это может быть архитектурный комитет на "хочу попробовать новую базу данных" или регламент работ на инцидентах на вопрос "зачем нужны дежурные?". И это ни в коем случае не должен быть процесс, который нельзя пройти или подвергнуть сомнению устоявшийся факт. Это должен быть такой процесс, который улучшает компанию, не подвергая ее значимым рискам.

Компания C. Корпорация.

Перейдя работать в крупную компанию на управляющую позицию я начал отмечать огромную важность долгосрочного планирования. Дело в том, что крупные компании не живут кварталами и даже полугодиями. По-настоящему крупные компании живут планированием и стратегией (здесь впервые применяется это слово) с проекцией на несколько лет. Дело в том, что крупные компании живут не только мыслью, как сделать классный продукт, но еще как сделать так, чтобы этот классный продукт был крупнейшим игроком на рынке. А это уже немного другое, чем планирование. Это стратегия. Здесь нужно учитывать не только свои собственные разработки, но и то, как будут развиваться другие игроки на рынке.

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

А где же "обратно" от Agile, спросит внимательный читатель?

Дело все в том, что как бы сильно вы не пытались познать и внедрить Agile - бывают моменты, когда он вредит.

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