Минимальный состав IT-команды: запустить проект и не разориться | АйТи-капитан объясняет

Привет, я Михаил, проект IT капитан. Сегодня 

поговорим про минимальный состав команды. Сначала посмотрим на полноценный процесс 

разработки и подумаем, как можно уменьшить количество ролей в команде, за счёт чего получим 

самый маленький вариант, минимально необходимый. И прикинем, как эволюционным путём мы можем 

прийти к следующему варианту и к следующему, как наш отдел разработки ПО будет расти, как 

это происходит в других компаниях. Поехали. Перед вами процесс разработки, развития и 

поставки пользователям успешного продукта, IT-продукта, то есть какого-то программного 

обеспечения. Если говорить о полноценном процессе, то вот это довольно неплохой его пример. Если 

мы говорим о какой-то большой компании, крупной, которую знаем мы все, например, известной, 

то таких команд там будет и 10, и 20, и даже больше. Но все с чего-то начинали. Здесь 

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

описан, применяется, практикуется десятилетиями. Ничего принципиально в нём не меняется. Но 

как же мы можем сократить количество ролей? Как мы можем сделать маленькую 

команду, если у нас не будет хватать специалистов? Сейчас покажу. Если вы 

смотрели моё видео про бизнес-аналитика, то там прозвучала одна очень важная 

фраза. Если у вас нет бизнес-аналитика, это не значит, что у вас нет бизнес-анализа. 

Бизнес-анализ происходит в любом случае. Просто им тогда занимаются либо все подряд, либо 

кто-то из смежной области. И так во всём. То есть, если мы говорим о том, что давайте, например, 

откажемся от дизайнеров, ну, нет у нас, например, требований к дизайну каких-то повышенных. Ну, 

простые там формочки, простые очень интерфейсы. Это значит, что дизайном будет заниматься 

у нас frontend разработчик вместе с продакт менеджером. Например, продактменеджер будет 

говорить о том, что здесь давай то разместим, здесь это, и фронтенд разработчик будет это 

реализовывать. Если мы говорим о том, что у нас нету отдела тестирования, тогда кто будет 

проверять наш продукт на ошибки? Тогда этим будут заниматься конечные пользователи, программисты 

сами же будут тыкать. И prodct менеджер, получается, Prodct owner тоже будет заходить, 

пытаться что-то проверить. если мы откажемся от QA. И так во всём. Давайте рассмотрим вариант 

Ультраэконом на следующем примере. Есть компания, которая занимается обслуживанием чего-либо. 

Это могут быть банкоматы, вендинговые аппараты, какое-то охранное оборудование. То есть у компании 

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

нужно программное обеспечение. Давайте посмотрим, кто бы это мог быть, какие роли нужны. Часто 

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

Чем восполняется отсутствие остальных ролей? Поскольку программное обеспечение это нужно 

для внутреннего использования, то к дизайну никаких требований не предъявляется. Не нужен 

DevOps, потому что проектом пользуются только ээ сотрудники компании, и сервера вообще могут 

находиться внутри. И может не быть какой-то масштабной микросервисной архитектуры, может 

быть только монолит, допустим, вот, ээ, вот так, например, вот так и всё. И бэкэнд разработчики 

вполне в состоянии сами раз там в двет недели выпускать новые версии, загружать на сервер. То 

есть продакшена, например, нет как такового. И DevOps тоже может не быть нужен. QA Но здесь, 

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

Они же и, получается, являются тестировщиками. Вот так. То есть вот вот эти ребята, 

пользователи. Далее менеджмент и бизнес-анализ. Поскольку есть основной вид деятельности 

компании, оказывает сервис, сервис по там обслуживанию каких-то аппаратных устройств, 

вот эти банкоматы, вендинговые аппараты, там есть технический специалист [музыка] руководящий, 

который во всём этом разбирается. Он же и берёт, например, под своё крыло программистов, которые 

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

для этих разработчиков Project и Prodct и бизнес-аналитикам. Саппорт. Аа просто инженеры 

приходят сами к руководителю и всё. вот к техническому, например, э-э специалисту или, может 

быть, у есть какой-то прожект-менеджер в компании, и к нему просто идут и всё. То есть вот эти вот 

все роли, они просто объединяются в какую-то одну в зависимости от структуры организации. Вот так. 

Теперь представим следующую ситуацию. компания по каким-то причинам начинает задумываться о том, что 

у неё есть вот этот вот IT продукт, проект пока что не продукт, проект, которым она пользуется. 

Вот это программное обеспечение вспомогательное, которое помогает организовать работу инженеров 

по обслуживанию какого-либо оборудования. Датчики шлют сигналы. Сигналы преобразуются в 

заявке, который должен принять инженер и осуществить выезд в какой-то промежуток 

времени определённый и мм закрыть заявку, а менеджер э следит за соблюдением сроков. Вот 

есть такой большой, там много функций, отчётности, картография, большой комплекс программный, 

который три разработчика, например, там в течение 5 лет вот так потихоньку делали, делали, 

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

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

регионах, которые не представляют для нас интерес, либо как-то, э, меняется ситуация на рынке, 

и компания отходит от своего основного вида деятельности. Что будет происходить дальше? 

Вариант два перспективный, условно мы с вами назвали, это мы сейчас придём к минимальному 

составу команды, если есть потребность в выпуске IT продукта на рынок. Вот наша задача 

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

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

в использовании. За это отвечают вот эти ребята. Далее, поскольку на продукт, 

скорее всего, возрастут нагрузки, то вот здесь появляется более сложная архитектура, 

и у нас появляется полноценный prodдаction сервер, который должен стабильно работать. Для всего 

этого мы нанимаем специально обученного человека. Это уже не задача и не тот уровень 

ответственности, который подошёл бы бэкэнд разработчиком, чтобы у пользователей всё работало 

стабильно и нам потом не огрести кучу проблем, мы должны тестировать наше ПВО. Мы должны 

узнавать о багах до пользователей, а не от них. Поэтому и нужны Q и система мониторинга. 

Далее, служба поддержки, но это неизбежно. Это стандарт в индустрии. Если пользователь 

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

проблемой. этого, в принципе, достаточно на этом этапе вот для того, чтобы оформить в 

продукт наше по, ну, разработчиков нужно добавить. Вот такой пример 

варианта два, перспективный. И суть в том, что между первым вариантом 

Ультраэконом и вариантом 2 перспективным огромная пропасть. Когда у нас только два-три разработчика, 

у нас по сути нет никаких процессов. Вот сидят три человека в кабинете, мы к ним заходим раз 

в день или два раза в день поздороваться, спросить, что по задачам, накинуть новых задач. 

там в мессенджере каком-то или просто на словах или письмом. Всё это не процесс по сути. А 

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

приключения, выстраивания, оптимизации бизнес-процессов, которые могут масштабироваться. 

Это уже совсем другой уровень и другой другая стадия развития компании и отдела. Ну, то 

есть, понимаете, да, вариант минимального состава команды напрямую зависит от того, 

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

пользователей, мы перестаём быть стартапом, а становимся продуктовой компанией, которой у 

которой есть свой продукт. которые занимаются продуктовой разработкой. И здесь начинаются 

интересности вот в этом секторе. Продуктовая разработка - это когда продукт-менеджер или 

productт ownр, мм, выстраивает видение проекта на рынке. Он определяет, что должно вообще 

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

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

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

То есть продуктмендмен - это что мы разрабатываем, что будет на проекте, а бизнес-анализ - это 

как именно оно будет вообще работать и как это внедрить в то, что у нас уже разработано. И 

здесь начинается интервьирование пользователей. Нужно с ними пообщаться, спросить, что им нужно, 

лояльных пользователей, так называемый каздеф. И начинается аб-тестирование. Мы смотрим 

на поведение пользователей при тех или иных изменениях. В общем, вводим метрики, 

анализируем. Мы начинаем работать чуть иначе. Не так, как мы работали, когда 

разрабатывали всё это просто для себя. И таким образом у нас появляется productджмент, 

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

всем этим управлять. У нас же техническая команда. Около варианта три я написал уверенный, потому что 

на этом этапе вы уже знаете, что делаете и зачем. уверены в своих действиях. У вас огромный 

объём работ и не получается уже размазать вот какие-то обязанности по уже имеющимся 

сотрудникам. Нет, у нас начинается такая специализация. Каждый занимается своим 

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

если только просто отдать разработку куда-то на сторону. Но если вы выстраиваете свой 

IT-отдел, то здесь уже очень много различных, если. И если рассматривать все эти если, видео 

просто будет бесконечным. Мы с вами до утра будем здесь сидеть и рассуждать. Я оставлю в описании 

под видео свои контакты, чтобы вы смогли связаться со мной и, может быть, какие-то вопросы задать, 

проконсультироваться. Всё, спасибо, до скорого. M.