Мы занимаемся проектной деятельностью, внедрениями на крупных предприятиях и холдингах и сейчас наша команда разработчиков состоит из 20 человек. Но так было не всегда.
Первый этап
Когда в штате всего 2 – 4 разработчика, коммуникация между ними довольно проста. Руководит всей компанией один человек, каждый сотрудник осознает свой круг задач, но при этом легко относится к выполнению смежных функций, не прописанных в должностной инструкции. Любой разработчик может быть немножко консультантом, немножко аналитиком и даже сисадмином.
На этом этапе небольшой отдел работает как часы. Все происходит быстро – и постановка задачи, и ее решение, и презентация результата клиенту. Многие заказчики предпочитают работать именно с такими, небольшими командами разработчиков
Однако стоит учесть, что профессиональный рост разработчиков быстрее происходит в крупных амбициозных проектах, которые немногочисленная команда просто не «потянет». Если компания надолго застрянет на этом этапе, есть риск того, что ведущие специалисты перестанут развиваться и со временем станут неконкурентоспособными. Кроме того, перед небольшой командой может встать проблема ограниченной специализации и отсутствия экспертности в некоторых областях, так как 2-4 человека не могут все знать и во всем разбираться. Неясные перспективы карьерного роста и повышения заработной платы, а также отсутствие мотивации могут вызвать отток сотрудников, что для маленькой команды заканчивается фатально.
Второй этап
Если первый этап компанией пройден успешно, то, скорее всего, у нее все в порядке с репутацией, и количество заказчиков постепенно растет. При этом разработчикам уже «не хватает рук» - возникает нехватка ресурсов и потребность в доборе персонала. Если вовремя не отреагировать на этот запрос, то могут появиться первые признаки недовольства со стороны заказчиков, связанные с тем, что задачи стали выполняться медленнее, а результат стал менее качественным.
На этом этапе происходит четкая дифференциация ролей - тратить дорогое время разработчика на консультирование по простым вопросам становится нерентабельным. Поэтому в команде появляются консультанты, аналитики и, при необходимости, другие специалисты.
Ключевые изменения для отдела:
- У отдела разработки появляется собственный руководитель - чаще всего это опытный разработчик с управленческими задатками. Он руководит коллективом, но при этом продолжает программировать и участвует в выполнении производственных задач.
- С появлением в команде новых участников, возникает необходимость организовать эффективное взаимодействие с ними, а также с руководителями других отделов.
- Меняются обязанности разработчиков. Они больше не занимаются консультированием пользователей. Любую коммуникацию между заказчиком и разработчиком обеспечивает консультант. Этот специалист получает всю необходимую информацию от заказчика, ставит задачи перед разработчиками, контролирует их выполнение и обеспечивает согласование результата с заказчиком. Также разработчики перестают выполнять функции, связанные с администрированием, установкой ПО и т.д.
Самый главный итог перехода на другой этап – возможность брать более крупные проекты и совершенствовать компетенции сотрудников. Разработчики не отвлекаются на рутину и вопросы, связанные с администрированием, у них появляется больше возможностей для роста и развития. Каждый занимается своим делом, и потребность в универсальных работниках отпадает.
На этом этапе остро встает вопрос мотивации сотрудников. Повышение заработной платы происходит точечно и не прозрачно
Третий этап
Когда количество разработчиков в команде приближается к 20, компания вынуждена перейти на следующий этап. Одна из его отличительных черт – руководитель постепенно перестает быть «играющим тренером», и сосредотачивается исключительно на стратегических управленческих задачах. Число совещаний и установочных встреч растёт в геометрической прогрессии - регулярно проходят как встречи и созвоны с заказчиками, так и внутренние совещания. Возникают проблемы с контролем и планированием, нагрузка на разработчиков становится неравномерной.
Отдел разработки на этом этапе может выглядеть примерно так:
Изменение процессов и рост подразделения требует изменений:
- Отдел разработки разбивается на небольшие группы по 3 – 4 человека и для каждой группы назначается тимлид, на которого возлагается часть обязанностей руководителя отдела. Тимлид контролирует загрузку своей группы и помогает по техническим вопросам. Руководитель получает информацию о работе отдела на планерках с тимлидами.
- На крупных проектах вводится новая позиция - «технический архитектор». Через него проходят все задачи, он прорабатывает техническую реализацию, вносит корректировки и дополняет задачи техническими деталями.
- Вводится планирование и разные инструменты контроля выполнения задач.
Если изменения внедрены успешно, отдел разработки приобретает следующий вид
Наличие тимлидов помогает отделу работать эффективнее. Разработчики не перегружены, задачи выполняются быстрее, коллеги из других отделов получают более оперативную обратную связь, появляются новые позиции, карьерный рост. У разработчиков, конечно, может сложиться впечатление, что кругом одни начальники, однако, чаще всего они относятся к этому факту благосклонно, понимая, что эта система облегчает их труд.
Четвертый этап
Развитие, обучение, мотивация. На текущем этапе вводится план по созданию комфортной среды для работы, стимулированию сотрудников к развитию и обучению, создание прозрачной оплаты труда.
Внутри отдела организуются митапы для обмена опытом, разработчики делятся друг с другом полезной информацией в формате доклада на заранее подготовленную тему. Это может быть узкоспециализированный технический доклад, доклад на прикладную тему и др. Важно и ценно, что такие доклады содержат в себе не только сухую теорию, но и обязательную практическую часть, подкрепленнную опытом работы в реальных проектах. Докладчик в процессе подготовки получает опыт и прокачивается, слушатели узнают что-то новое или вспоминают забытое старое, происходит общение, и коммуникация между коллегами, с которыми в обычное время общение происходит не часто.
Тимлид составляет индивидуальные планы развития сотрудников. В план развития вносятся цели на год, в том числе сертификация.
Разрабатывается и внедряется грейдирование,рост заработной платы становится прогнозируемым для руководства компании и прозрачным для рядовых сотрудников.
Карьерные возможности специалиста в ИСВС
Молодой специалист поступает на работу в качестве программиста-джуна (первый уровень) с умением самостоятельно решать лишь несложные типовые задачи. Через некоторое время он переходит на следующий уровень, оставаясь формально джуном.
Овладев сертификатом 1С Специалист по платформе, джун переходит в категорию миддлов. Отсюда у него есть два пути, либо совершенствоваться в разработке и двигаться в сторону навыков сеньора или эксперта, либо уйти в тимлиды. Со второго уровня миддлов можно также стать техническим архитектором. Венец эволюции разработчика – звание эксперта. Специалисты такого класса имеет опыт оптимизации механизмов и сертификат 1С Эксперт или комплект сертификатов по предметной области (Профессионал + Специалист + Специалист-консультант).
