О роли технического директора

Чем занимается технический директор?

Признаки того, что IT-директор занимается не своей работой

• IT-директор несет ответственность за программное обеспечение в компании.
• Нет контроля за отчуждаемостью программного обеспечения. Конфликт исполнителя и ревизора в одном департаменте.
• Обмен между различными сервисами предприятия (middleware-контур) централизован.
• Руководители департаментов не несут ответственности за изменения и только эксплуатируют уже созданный софт.
• Руководители департаментов явно или неявно не могут сменить подрядчика в IT.
• Технический директор — единая точка выбора подрядчиков. Сложные процедуры проведения тендера или формирования команды.
• IT-директор — прораб для разработчиков. Думает только о внедрении конкретных продуктов.
• Технический директор руководит внедрением каждой отдельной программы.
• Разные департаменты работают в единых программных комплексах.

Так должно быть

• IT-директор несет ответственность за грамотность руководителей департаментов в области управления разработкой программного обеспечения.
• Через введение стандартов и проведение аудитов технический директор контролирует передаваемость программного обеспечения. В некоторых случаях отвечает за инфраструктуру команд (если она не облачная).Middleware-контур определен, за ETL (коннекторы) и хранилища информации конкретных сервисов отвечают ответственные за конечные сервисы.
• Руководители департаментов несут полную ответственность за свой софт.
• Руководители департаментов могут сменить подрядчиков в любой момент.
• Руководители департаментов несут полную ответственность за выбранного подрядчика, а потому выбирают и меняют его, как им удобно.
• IT-директор — аудитор для IT-команд, которые предоставил бизнес.
• Разрабатывает общие для всех отделов правила внедрения продуктов.
• Проводит аудит решений (на безопасность, на скорость изменений). Внедрением ПО для отдела руководит глава этого отдела.
• Каждый департамент работает в собственных решениях.

Какие стандарты должны исходить из IT-отдела и от IT-директора?

Не такие

• Парадигма «идеальной архитектуры», не допускающей ошибок.
• «Используйте только .php» (или любой другой язык, фреймворк, технологию).
• «Сами решайте, какие связи должны быть между продуктами и сервисами в контуре вашего отдела». Сервисы явно «знают» друг друга.

Так правильно

• Парадигма резистентности к ошибкам. В конечных сервисах могут быть ошибки, но они не должны привести к ошибкам и уязвимостям в других сервисах.
• Требования по обмену между приложениями. Методология обеспечения качественного программного обеспечения вне зависимости от языка.
• Стандарт запрещает сильное связывание. Сервисы явно не «знают» друг про друга.

Подробнее см. в видео