Как стать автором
Обновить

Комментарии 4

Если в компании для определения должностных обязанностей требуется проводить целое исследование (возникают проблемы с их четким и понятным определением), то может ей просто не нужен "технический директор"?

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

  1. Техдир имеет большой опыт и прекрасно знает что должен делать.

  2. Техдир или компания так и не вышли из стадии "техдир - это такой самый сильный программист в конторе"

В теории список хорош, но на практике...

  • Определение общих стратегий технического развития - Стратегии определены, но по факту не используются;

  • Принятие глобальных технических решений - решения используются, но не по назначению :)

  • Внутренний технический арбитраж - практикуется, но нет результата, или есть побочные эффекты;

  • Выбор технологий, которые будут использоваться в том или ином проекте - технологии выбраны, но они постоянно меняются;

  • Оценка этих технологий в плане финансовых и временных затрат - для оценки использованы неактуальные и не наиболее приоритетные показатели;

  • Оценка длительности и трудоемкости проектов - размыта;

  • Планирование и построение процессов разработки - осуществляется без связи с требованиями бизнеса;

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

  • Распределение задач между командами - как всегда неоптимальное;

  • Отслеживание продвижения проектов - на 99% завершены;

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

  • Выбор и внедрение вспомогательных систем для разработки и администрации - постоянное улучшение, изменение и замена этих систем;

  • Экспертные предложения по архитектуре или конкретным техническим решениям - старания предложить решения best practices, которые по отзывам работают, но не у вас;

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

  • Технический pre-sale ключевых проектов - недостаточно опыта для проведения пресейлов;

  • Управление техническими рисками на проектах - воспоминания о прошлых фейлах;

  • Общение с другими отделами и топ-менеджерами компании (CEO, COO, CIO и др.) - стремление выглядеть на уровне;

  • Координация работы департаментов - безуспешные (не всегда) попытки угодить всем;

  • Технические собеседования с новыми сотрудниками - показательное превосходство;

  • Оценка продуктивности сотрудников и решение об уровне их зарплат - принимаются спонтанно;

  • Обучение сотрудников - с минимальными финансовыми затратами и максимальными требованиями отдачи;

  • Формирование рабочей атмосферы в коллективе, мотивация сотрудников - поиск точек соприкосновения (не так уж и плохо);

  • Разборы полетов с тимлидами - попытки понять кто неправ и переложить ответственность;

Спасибо за дельный комментарий)

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации