Мой путь в управлении IT коллективами начался весьма внезапно, а именно в ситуации "А что если мы сделаем A, B, C и будем продавать этот продукт на рынок?" Забегая немного вперед, можно отметить что этот опыт не увенчался успехом. Но судя по всему мне удалось набить немало ценных шишек, чему-то научиться и, возможно, для кого-то это будет полезной статьей, чтобы количество таких шишек сократить.
![](https://habrastorage.org/getpro/habr/upload_files/c75/76f/4e0/c7576f4e0854c4240ba911d82b8bcb3f.jpg)
На мой взгляд, помимо классических и везде упоминаемых факторов вида "команда", "мотивация", "продукт" практически всегда из поля зрения ускользают "налаженные процессы". Я беру ответственность утверждать, что в какой-то момент это даже более важный фактор, чем слепая мотивация работать по 10 часов в день. И здесь даже речь не про классическое выгорание, а про то, что в какой-то момент становится гораздо проще сломать одним релизом слишком много звеньев в цепочке, чем принести пользы тем же самым релизом без багов. В какой-то момент без налаженных процессов становится слишком просто топтаться на одном месте, тратя на это безумно много сил.
Компания A. Когда все начиналось.
Как я уже упоминал выше, данная компания образовалась внезапно и нашей целью было не много, ни мало - а именно построить каркас для массовой интеграции моделей ML в энергопромышленность. На тот момент мы не знали ничего о планировании, о грамотном бюджетировании, не просчитывали риски и на соответствующие вопросы предполагаемых к сотрудничеству компаний отвечали непонимающим взглядом и мыслями "вы что, не понимаете, как сильно это может вам упростить жизнь?".
Важный момент, который стоит осознать здесь, что для компании в первую очередь важна прибыль. А прибыль это есть ни что иное, как отношение полезной работы к рискам. И вот в тот момент, когда значение этой дроби становится меньше 1 - компания должна сильно задуматься над тем, что она делает. Именно разбившись об это простое правило наши гениальные идеи и потерпели крах.
Компания В. Или первая работа по найму.
Формально в данную компанию я пришел уже (как я считал) с каким-то багажом знаний и именно с целью управлять IT коллективом. Стоит отметить, что на тот момент в компании было ровно так, как указано в заголовке статьи. У членов коллектива была какая-то цель и они как-то ей придерживались.
Я уже понимал про необходимость встреч и статусов; я уже знал про Jira и Confluence. Единственное, что я не понимал - это "зачем" это. Тем не менее мне не помешало начать внедрять это и стоит признать даже минимальная систематизация работы дает свои плоды. Но есть важный момент, что в IT коллективе существует очень тонкая грань между "ок, давайте вести таски" и "ок, вместо задач буду вести таски". Члены коллектива, которые делают классный и инновационный продукт - обычно хотят делать именно его, а не таски в Jira. Я утверждаю, что грамотный руководитель должен чувствовать это и балансировать между этими двумя состояниями не хуже канатоходца над водопадом Виктория. Да, безусловно нужны ежедневные митинги, недельное планирование и ретро встречи. Но если вы чувствуете, что ваши разработчики или аналитики вот-вот сделают то, к чему так долго стремились, а у вас в календаре ретро - перенесите.
![](https://habrastorage.org/getpro/habr/upload_files/a8c/43a/072/a8c43a072ea32ea8c7ecfaca4c92064e.png)
Не менее важно начать выстраивать в компании процессы. Но что же такое процессы и зачем они нужны?
По моему убеждению процессы это то, что регламентирует жизнь коллектива и даже в случае, если вы (как создатель процесса) заболели, улетели или уволились - оно будет продолжать работать как швейцарские часы. К сожалению, без этого хаос настигает коллектив незаметно, как снежный ком. Разработчики хотят пробовать новые технологии, data science команды хотят воплощать в жизнь новые статьи. Хочется? Докажите, что это необходимо, покажите что от этого будет профит. Вам, как руководителю просто необходимо иметь ясную и задокументированную последовательность действий практически на любое "хочу" или "зачем". Это может быть архитектурный комитет на "хочу попробовать новую базу данных" или регламент работ на инцидентах на вопрос "зачем нужны дежурные?". И это ни в коем случае не должен быть процесс, который нельзя пройти или подвергнуть сомнению устоявшийся факт. Это должен быть такой процесс, который улучшает компанию, не подвергая ее значимым рискам.
![](https://habrastorage.org/getpro/habr/upload_files/366/0da/a31/3660daa31ca325fd3879a7fffd0ec094.jpg)
Компания C. Корпорация.
Перейдя работать в крупную компанию на управляющую позицию я начал отмечать огромную важность долгосрочного планирования. Дело в том, что крупные компании не живут кварталами и даже полугодиями. По-настоящему крупные компании живут планированием и стратегией (здесь впервые применяется это слово) с проекцией на несколько лет. Дело в том, что крупные компании живут не только мыслью, как сделать классный продукт, но еще как сделать так, чтобы этот классный продукт был крупнейшим игроком на рынке. А это уже немного другое, чем планирование. Это стратегия. Здесь нужно учитывать не только свои собственные разработки, но и то, как будут развиваться другие игроки на рынке.
Так же в крупных компаниях становится очень важным фактор встреч формата 1х1. Дело в том, что когда вы работаете в небольших компаниях вы можете все держать на кончиках пальцев, но в больших организациях слишком много внешних связей и контактов - пальцев, к сожалению, не хватит.
А где же "обратно" от Agile, спросит внимательный читатель?
![](https://habrastorage.org/getpro/habr/upload_files/a01/0f7/430/a010f74301535abe3051fa553fa7b8d1.jpg)
Дело все в том, что как бы сильно вы не пытались познать и внедрить Agile - бывают моменты, когда он вредит.
В частности примером такого фактора является работа на инцидентах. Когда ваша система не может зачарджить клиента, хотя должна делать сотни чарджей в секунду с разных клиентов - это инцидент и исправить его нужно asap и "как нибудь" (конечно, не навредя сильнее). В целом, практически все то, что дополняется "asap" - не про Agile.
Не стоит забывать, что Agile это просто методология и, вероятно, наиболее важная часть этой методологии это умение отходить от заранее выбранного пути. Я утверждаю, что стоит уметь применять это правило не только к проектам, но и к самой методологии в целом.
Комментарии (4)
irony_iron
08.12.2022 08:17+2забавно, вы описали вещи которые я как технический специалист буквально из фирмы в фирму встречаю, где по мере роста компании одни и те же проблемы роста управленцы пытаются решать не регламентированием процессов и изучением продукта, а внедрением аджайла по методичке
auddu_k
08.12.2022 08:32+1Очень интересная тема, но, если честно, вывод не уловил: ну да, чистый аджайл не применим к большой компании, потому что компания - это не команда и управлять ей нужно по другому ????♂️
Немного личного опыта: при всех проблемах аджайл-команда, если удастся ее построить (это важно), может вполне эффективно действовать и развивать продукт и в большой компании.
dyadyaSerezha
Нет, я бы на основе "стабильное место на рынке", "стабильная прибыль" или "много инвесторов", "зарплаты выше рынка". При чем тут команда и мотивация? Да пусть хоть каждые полгода команду меняют и та работает без мотивации - только врядли это получится при остальных упомянутых качествах.
Дальше статью не читал ещё. Пошёл читать.)
Gryphon88
То же впечатление. Перечисленное средства, а не цели, если зарабатываешь и обоснованно планируешь продолжать, организовав из подчиненных токсичную потогонку, зачем что-то менять?