Болезни роста: эволюция отдела разработки

12.04.24

Команда - Коммуникации

Многие руководители считают, что сто человек работают в сто раз эффективнее, чем один. Однако масштабирование – нелинейный процесс. Производительность большой команды не всегда равна сумме производительностей ее членов. Как сделать так, чтобы члены команды усиливали друг друга, а не тормозили? Компания ИСВС проходила этот путь и знает ответ!

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

Первый этап

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

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

 

 

Однако стоит учесть, что профессиональный рост разработчиков быстрее происходит в крупных амбициозных проектах, которые немногочисленная команда просто не «потянет». Если компания надолго застрянет на этом этапе,  есть риск того, что ведущие специалисты перестанут развиваться и со временем станут неконкурентоспособными.  Кроме того, перед небольшой командой может встать проблема ограниченной специализации и отсутствия экспертности в некоторых областях, так как 2-4 человека не могут все знать и во всем разбираться. Неясные перспективы карьерного роста и повышения заработной платы, а также отсутствие мотивации могут вызвать отток сотрудников, что для маленькой команды  заканчивается фатально.

Второй этап

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

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

Ключевые изменения для отдела:

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

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

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

 

 

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

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

Третий этап

Когда количество разработчиков в команде приближается к 20, компания вынуждена перейти на следующий этап.  Одна из его отличительных черт – руководитель постепенно перестает быть «играющим тренером», и сосредотачивается исключительно на стратегических управленческих задачах. Число совещаний и установочных встреч растёт в геометрической прогрессии - регулярно проходят как встречи и созвоны с заказчиками, так и внутренние совещания. Возникают проблемы с контролем и планированием, нагрузка на разработчиков становится неравномерной.

Отдел разработки на этом этапе может выглядеть примерно так:


 

Изменение процессов и рост подразделения требует изменений:

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

-         На крупных проектах вводится новая позиция - «технический архитектор». Через него проходят все задачи, он прорабатывает техническую реализацию, вносит корректировки  и дополняет задачи техническими деталями.

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

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

 

 


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

Четвертый этап

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

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

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

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

Карьерные возможности специалиста в ИСВС

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

Овладев сертификатом 1С Специалист по платформе, джун переходит в категорию миддлов. Отсюда у него есть два пути, либо совершенствоваться в разработке и двигаться в сторону навыков сеньора или эксперта, либо уйти в тимлиды. Со второго уровня миддлов можно также стать техническим архитектором.  Венец эволюции разработчика – звание эксперта. Специалисты такого класса имеет опыт оптимизации механизмов и сертификат 1С Эксперт или комплект сертификатов по предметной области (Профессионал + Специалист + Специалист-консультант).  


Управление руководство система отдел разработки схема

См. также

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

Коммуникации Бесплатно (free)

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

27.02.2024    1275    0    user1561517    3    

14

Гореть, но не выгорать: как сохранить ресурс специалистов

Коммуникации Мотивация Личная эффективность Бесплатно (free)

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

15.01.2024    1962    0    KChebykina    0    

32

DevRel: почему им стоит заняться уже сегодня

Коммуникации Обучение и наставничество Бесплатно (free)

DevRel (developer relations или просто технический пиар) – направление развития и поддержки IT-бренда компании: почти как PR (Public Relations), только в центре внимания находятся технические процессы и технологии, а не маркетинг. О том, зачем DevRel нужен компаниям, какие есть форматы, кто уже запустил DevRel, что из этого получилось, и почему это становится трендом, пойдет речь в статье.

09.01.2024    2086    0    a_plastinin    2    

19

Завал в IT-компании и как с ним бороться

Коммуникации Россия Бесплатно (free)

Работа в режиме завала и в режиме нарастающего завала. Для простоты изложения возьмем конвейерное производство. Конвейер традиционно делится на участки (на множество участков). На каждом участке конвейера есть сотрудник, который выполняет определенный процесс или занимает позицию «наблюдателя» - стандартный руководитель. Представим картину: на таком производстве в середине смены, кто-то упустил определенный момент и все, что находится на конвейере падает на пол. Вот тут и начинается: "Все бегают, суетятся и проклинают виновника и в экстренном порядке пытаются придумать «что-то»".

25.12.2023    836    0    simon_sidoruk    1    

6

Синергия аналитика и разработчика

Коммуникации Бесплатно (free)

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

19.12.2023    1218    0    Fecolka    1    

11

Мастер-класс «Строим команду мечты через people-management»

Коммуникации Мотивация Бесплатно (free)

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

18.12.2023    716    0    user1544625    0    

5

Радио "Аналитик", 8 выпуск 2 сезона. Про сложные разговоры с Юрием Клименко

Коммуникации

В восьмом выпуске второго сезона подкаста Радио “Аналитик“ поговорили о переговорах, конфликтах и навыках, которые необходимы для продуктивного общения с коллегами и клиентами.

11.12.2023    330    0    Radio_Analyst    0    

3

«Таких не берут в космонавты»: тонкие сигналы в подборе и оценке кандидатов

Коммуникации Бесплатно (free)

Помимо Hard skills, Soft skills – того, что может нарабатываться с опытом, есть «личные особенности» и «модели поведения». Именно эти факторы являются наиболее критичными при отборе сотрудников. Расскажем, как можно из резюме выявить типичные модели поведения и особенности кандидатов, проверить свои гипотезы в интервью; на что обращать внимание в истории и поведении кандидата, и какие «нерабочие» вопросы задавать, чтобы в непринужденной беседе получить больше информации, чем при профессиональном отборе.

04.12.2023    1212    0    e_ivanova    8    

4
Комментарии
Подписаться на ответы Инфостарт бот Сортировка: Древо развёрнутое
Свернуть все
1. Birby 111 12.04.24 11:05 Сейчас в теме
Спасибо за отличную статью!
2. chuklay 196 12.04.24 17:51 Сейчас в теме
Спасибо за статью! Кто в вашем случае на 3 этапе взаимодействует с сотрудниками других отделов? Руководитель отдела разработки? Или прежде всего тимлиды также участвуют в коммуникациях по задачам напрямую с консультантами-аналитиками?
80lvlAPP; vasilnikol; +2 Ответить
12. Serega182 15.04.24 10:47 Сейчас в теме
(2) Действительно интересный вопрос.
user1756575; 80lvlAPP; chuklay; +3 Ответить
13. vasilnikol 103 15.04.24 10:52 Сейчас в теме
(2)Спасибо за вопрос. Все задачи через тимлида к разработчику поступают от аналитического отдела. Постановщиком у задачи для разработчика является консультант/аналитик и разработчик на прямую коммуницирует с консультантом/аналитиком при выполнении задачи. Тимлид подключается к обсуждению задачи при необходимости, если задача сложная, срочная, есть проблемы и т.д.
serg3525; Disarus; NCH; chuklay; +4 Ответить
3. booksfill 12.04.24 18:25 Сейчас в теме
Пятничное ворчание. Читать не обязательно.
Обычный зуд, когда домой рановато, а делать уже особо нечего и хочется самовыразиться. :)

Где-то между 3-им и 4-м этапом начинается, параллельный финишный этап.
Проводя аналогию со стадиями зрелости, я бы назвал его "гниение".
Начинается он с такого понятного SMART, точнее буквы "M" – measurability (измеримость).
Ну как можно управлять чем-то, не измеряя?
Вооот!

Поэтому нужна четкая система показателей, УСЛОВНО назовем ее KPI.
О! Мы не забываем конечную цель! Остальное добираем докладами/митапами, наставничеством, правильным составлением инд. планов, сертификатами, своевременными явками, отчетами о проделанной работе и т.п.

Это ведь логично и правильно: надо учить смену, делиться знаниями, заниматься самообразованием, социализироваться, чтобы это не значило?
Конечно надо!

Как-то само собой, начинает получаться, что основная деятельность уходит в тень.
Она, по-прежнему, неудобная, т.к. от этих KPI "меряться" лучше не стала. А вот чувствует себя уже не важно.

Ну, наверное, KPI считаем как-то не так, давайте переделаем, а потом еще раз.
Руководители быстро превращаются в учетчиков: кто сколько докладов написал, кто сколько кого "отнаставничал" по самое не балуйся, кто сколько курсов прослушал.
Легко, понятно, графики, опять же красивые, вот только что-то все чаще заказчики уходят и денежек все меньше.

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

Ах, да, и аттестации с сертификациями! Как можно больше. И плевать, что познания действительно нужные не вполне вписываются в Геракла. Пущай готовятся - лишних знаний не бывает.
И не забалуются, оценивать будем строго: " Я сделал это не в интересах истины, а в интересах правды" (С) Золотой теленок.

А может себе оклад сделать побольше и работать не по 10, а по 14 часов, контролировать каждый "ихий" шаг?
Не, говорят, что микроменеджмент - плохо, надо просто уволить тех, кто тянет команду назад и взять тех кто может еще больше в доклады и сертификаты.

И пусть "их" никто не отвлекает всякими там общениями с заказчиками, для того есть специально обученные люди.
И плевать, что даже в микроцепочке заказчик – исполнитель взаимопонимание, в идеальном случае, процентов 80 и то где-то после 3-5 встречи.
Добавим туда еще звеньев и поиграем в испорченный телефон.
Ведь не может же что-то случиться, когда в цепочке такие уважаемые люди, как менеджер по продажам (а откуда вы денежки брать собрались?), аналитик, архитектор, тимлид?
Ведь не может же? Правда?

В общем, когда люди перестают думать в терминах дела, то начинается итальянская забастовка руководителей, когда формально придраться не к чему, а по сути дело умирает.
И в описании 4-го этапа почему-то мне четко видится признак с косой того самого финального.
Наверное, потому, что пятница и вообще.
Dem1urg; ovasiliev; _DaFNa_; SirStefan; EvgeniyOlxovskiy; +5 Ответить
4. siamagic 12.04.24 18:48 Сейчас в теме
Лол ))) в целом статья интересная, но заканчивается абсурдом - сидят два человека один дятел с сертификатом, другой нормальный прог, но без него (потому что платите за то чтоб я это зубрил или тупо лень). У нас в "глубинях" любой нормальный прог и аналитик и консультант и администратор, причем не напряжено, "технический архитектор" звучит как гей - нормальный прог распишет что и куда, ему не нужны советы гея.
5. gybson 12.04.24 19:35 Сейчас в теме
(4) Нормальный прог это кто-то сразу после окончания университета, а кто-то лет через пять после него. Т.е. в норме это почти каждый после 25-26, ну ближе к 30 точно. И представьте себе, после 30 люди не умирают и не останавливаются в развитии. Далее начинается действительно узкая специализация. В программирование, аналитику, руководство, девопс, разное. И, главное, спесь слетает, как не было :)
7. siamagic 13.04.24 12:21 Сейчас в теме
(5) Я ближе к 40, спесь не слетела, во франчайзи есть деление, на предприятиях нету. Приходят проги из франча - олени в том смысле что шаг влево вправо - не знают что делать (в яндексе ума не хватает набрать, зато вот он сертификат и на собеседование на все тупые вопросы ответил), аналитики туда же - влево вправо "мы этого не проходили", ну и кто быстрей решить проблему аналитик читая итс или я глянув код? Читерство, но всё же. Девопс вообще смешно - набор скриптов с инструкцией для обезьян на каждом столбе.

И вот нанимаешь подрядчика - лучшего в России в своей сфере и это стадо макак делают такой лютый трешак, пролюбив все сроки, что потом сидишь и всё переписываешь, за сильно меньшее время, работающие в 10 раз быстрей . К аналитикам, правда, там претензии нету - пользователям всё рассказали и ответили на все вопросы, даже инструкции написали с картинками вида "Вот справочник Статьи затрат, для ввода нового элемента нажать добавить, указать наименование статьи и счет" хах)))) Картинки видимо для веса, инструкция 500 страниц, стоимость пол мульта ))))))
Andrekaa; SirStefan; shard; vakham; YA_1130000057973079; +5 2 Ответить
6. gybson 12.04.24 21:18 Сейчас в теме
Бывает, что до 4 этапа доходит и длится без создания иерархии. Но это без заказчиков и конкуренции.
8. van_za 248 13.04.24 16:13 Сейчас в теме
Добротная статья, по делу и без лишних понтов
user1756575; 80lvlAPP; Disarus; +3 Ответить
9. Ulus 289 15.04.24 05:49 Сейчас в теме
Хорошая статья и ход мысли и эволюции верен. Прочитал с удовольствием.
Но вы зациклились на отделе разработки и "ядро" статьи как он эволюционировал.
И лишь вскольз задели появление "аналитического отдела"
А это не так, особенно на крупных проектах.

Тащит проект ФА(функциональный архитектор) + Команда аналитиков.
Именно "мясо и передовая" тут в связке: ФА+ Аналитики.
Именно эта связка определит как бизнес модель работы предприятия "ляжет в 1С" и именно тут успешность проекта.
И если связка ФА+Аналитики мощная, она дает на выходе грамотные функциональные разрывы и в бой вступает
"ТА+ разрабы"
Прим ТА - технический архитектор ....

Не компетентные разрабы дадут только:
- тех долг, который копится и проявляется не сразу
- срыв сроков, ибо не "закодили" ТЗ вовремя
- более болезненный старт "промышленная эксплуатация", т.к. выдадут дикую сыромятину. Это сыромятина ляжет болью на тех же аналитиков...

Я не говорю о том что ФА + аналитике важнее, чем ТА + разрабы.
Нет
Все целостно и все едино ... И должно быть сбалансировано
А у вас как раз все под одним углом зрения.
bobaG; 80lvlAPP; NCH; EvgeniyOlxovskiy; +4 Ответить
10. DoubleT 7 15.04.24 07:16 Сейчас в теме
Спасибо!
Вопрос, а консультанты у Вас входят в эту группу из 3-4 человек? У них такая же схема мотивации и роста?
14. vasilnikol 103 15.04.24 10:54 Сейчас в теме
(10)Спасибо за проявленный интерес. Консультанты работают в другом отделе и в эту схему не входят, у них своя система роста и мотивации.
serg3525; Disarus; +2 Ответить
11. Oleg_nsk 279 15.04.24 08:40 Сейчас в теме
Т.е. в вашу компанию специалист с большим опытом, но без сертификата может устроиться только джуном?
15. vasilnikol 103 15.04.24 10:54 Сейчас в теме
(11)Спасибо за вопрос. Мы принимаем сотрудников и без сертификатов, определяем его в грейд исходя из уровня разработчика. Но за разработчиком образуется условно техдолг. Для того, чтобы двигаться дальше по карьерной лестнице, необходимо будет закрыть долг по сертификатам.
serg3525; Disarus; +2 Ответить
17. Oleg_nsk 279 15.04.24 12:39 Сейчас в теме
(15) Если честно - непонятное требование. На мой взгляд с таким подходом вы просто теряете кадры при нынешней конъюнктуре рынка труда. Какой стимул у сеньора, начинать работать у вас сразу с техдолгом, если он может легко устроиться в другую компанию без техдолга? Вы предлагаете завышенные зарплаты или еще какие-то привилегии, которых нет у других?
18. John_d 5447 15.04.24 12:52 Сейчас в теме
(17) так говорят же что не теряют, а берут, но с условием получить сертификат в будущем.
Так что это будет хорошая мотивация наконец получить сертификат.
user1756575; serg3525; 80lvlAPP; vasilnikol; +4 Ответить
16. vakham 21 15.04.24 11:09 Сейчас в теме
Как утверждают психологи (и история), человек (средний по больнице) может постоянно отслеживать до 3-х объектов. Относительный контроль до 7 объектов. Наша армия, как бюрократический объект, который подвергся стрессу в боевых условиях ВОВ, пришёл к троичной системе: рота-три отделения, батальон-три роты, дивизия-три полка. Опять же, в книгах типа "бухгалтерия для чайников" отдел бухов рекомендовался в 5-7 человек. Всякие игрухи делают группы в среднем в 5 чел. Бригады хирургов, мед.отделения, слесари, шахтёры-проходчики... Психика человека такова, что: 3 - это ключевые непосредственные подчинённые, 7 - предел (ключевые+поддержка).
Как только "группа" выросла до 10 рыл, требуется деление и переподчинение.
80lvlAPP; olexi2012; +2 Ответить
19. ovasiliev 6 22.04.24 04:45 Сейчас в теме
"Схема развития сотрудников отдела разработки" в данном изложении - это довольно распространённое представление о впоросе менеджера, имеющего весьма отдалённое отношение к 1С.
Один только пункт для миддла - "Знание типовых конфигураций - 3 конфигурации" уже говорит о профанации. На вопросе "Какие конфигурации знаете" я всегда теряю интерес к его задающему, ибо говорить с ним не о чем.
Скажите мне, что значит "знать конфигурацию"? На этот вопрос не ответит никто. Одну конкретную конфигурацию в полной мере не знает даже её разработчик, ибо их там команда, и каждый отвечает за свою область.
И от человека, имеющего "специалиста-консультанта" по конфигурации, можно ждать весьма схематического знания предмета, в той или иной мере. Ему можно ставить задачи, и он будет разбираться в каждом конкретном вопросе, в каждой конкретной задаче. Это вам не таблица умножения, это прикладная сфера.
Специалист 1С ценен именно способностью разобраться в задаче и решить её, ввиду в первую очередь склада своего ума, уровня аналитического мышления и набора технических компетенций и опыта.
Это обычная и очень распространённая история - посредственный программист становится никудышным руководителем, и в результате отдел превращается в болото. Ну и ладно, пусть скажут спасибо и на этом. Всё равно никто не понимает, чем мы тут занимаемся.
Оставьте свое сообщение