В этой заметке я хочу бегло ознакомить читателя с моим подходом к внутренним процессам технического департамента, связанным с разработкой программного обеспечения.
Проблема. Я не планировал подробно вдаваться в тему, поскольку цикл заметок предназначался для начинающих технических директоров небольших компаний. Я предполагаю, что если вы решили взять новую высоту, то стартовали минимум с позиции руководителя группы разработки, следовательно, четко представляете, как нужно организовывать работу коллег-программистов и верстальщиков, представляете, как работает дизайнер и что ждать от тестировщиков.
Мысли. Тем не менее, изложу несколько своих соображений на этот счет.
Работа технического директора очень многогранна. В идеале, каждый тип работ у вас будет выполнять специально обученный сотрудник, например, архитектуру приложения будет разрабатывать архитектор, техническую документацию будет писать технический писатель, дизайн будет делать дизайнер, кадры подбирать – сотрудник HR и т.д. Но в небольших компаниях не всегда получается взять на каждую должность отдельного человека.
Проектирование. Я для себя определил следующую стратегию развития своих технических департаментов – разработку я делегирую своему заместителю. Для этого я ищу очень хорошего специалиста, который в состоянии возглавить группу разработки и полностью ее контролировать. Выбор СУБД, фреймворков и операционных систем я оставляю за ним. На этом этапе я выбираю лишь технологии, но в детали не лезу. Пусть решают сами. Специалист сможет решить задачу быстрее и качественнее, если будет пользоваться уже знакомыми инструментами.
Мне достаются организационные моменты, а руководителю группы разработки – техника.
Фактически всегда руководители моих групп разработки совмещают в себе функции тим-лида и системного архитектора.
Разработка. В разработке я отдаю предпочтение тому, с чем работал сам:
Тестирование. С тестированием точно такой же подход. Типы применяемых видов тестирования зависят от задач и доступных ресурсов:
Решая задачи тестирования помните, что программист сам не в состоянии качественно проверить свой программный продукт, и совсем без тестировщиков обойтись нельзя.
Техническая поддержка тоже очень сильно зависит от требований к вашему программному обеспечению.
Самый простой способ при небольших нагрузках – завести всю поддержку на себя, указав свой адрес электронной почты и мобильный телефон. Это позволит быть всегда в курсе дел и иметь возможность самостоятельного выбора решения в критической ситуации. Но это подойдет далеко не всем, потому что при таком подходе ночью спать проблематично.
Второй способ – делегировать эти полномочия на руководителя группы разработки, но в таком случае эти условия надо согласовать с ним при приеме на работу. Руководящая должность подразумевает повышенный уровень ответственности, поэтому не думаю, что с этим возникнут проблемы.
Третий способ – купить услуги Call-центра. Девочки на телефоне будут собирать информацию о проблемах клиентов и заводить заявки в вашу систему ServiceDesk. Спать станет спокойнее, но при этом увеличится время реакции на критические проблемы. Что важнее – решать уже вам.
Эти три способа очень хорошо дополнят системы автоматического мониторинга с уведомлением на электронную почту и sms на телефон. Nagios никогда не спит!
Если позволяют ресурсы, то можно организовать службу технической поддержки в своем департаменте и делегировать решение проблем тех.поддержки специально обученным людям. Делегирование полномочий – прекрасная вещь!
Практика. Оперативное исправление ошибок в нерабочее время я организую с помощью дежурного программиста. Я предлагаю самому толковому программисту небольшую прибавку к жалованию в размере 10-15 000 рублей за доступность в режиме 24/7. Выделяется модем и ноутбук. Организовывать дежурство среди программистов достаточно муторно, да и это будет воспринято как ухудшение условий труда в компании. А так получается, что есть единая точка входа для всех сотрудников компании.
Вывод. Решение задач разработки, тестирования и технической поддержки я стараюсь делегировать своим руководителям групп, ограничиваясь лишь регулярным контролем. Ваши руководители групп – ваши правые руки, поэтому их надо подбирать так, что бы можно было работать по принципу «дал задачу и забыл», зная, что все будет выполнено точно и в срок.
Это был последний пост из цикла заметок «Технический департамент своими руками». В будущем я планирую добавить несколько заметок, например, на тему ведения проектов.
Спасибо всем, кто дочитал до конца.
