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

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

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

Ваша основная работа как руководителя ИТ будет роль — секретаря. Да, вы руководитель компании, бизнесмен, вы должны отработать секретарем, чтобы проект был успешен, вам следует обратить внимание на следующие моменты.

1. Ответственность и отвечать за взятые на себя обязательства.

Итак, вы запустили построили команду, наладили коммуникации, управляете изменениями, идет проект, что же делать дальше? Дальше вам необходимо заставить ваших сотрудников научиться брать на себя ответственность и отвечать за то, на что они подписываются.

Заметьте, я специально разделил «брать на себя ответственность» и «отвечать» за результат, почему? Если вы работает с хорошими ребятами, и у вас отличные дружеские отношения, вы наверняка часто слышали, да без проблем, давайте сделаем сайт за 3 часа, мы же дерзкие, классные и умные. Ваш главный разработчик встает и говорит отлично, сделаем за три часа — это называется «брать ответственность». И тут возникает страшный, неприятный и подлый подводный камень, который вас, как руководителя ИТ, будет преследовать всю вашу жизнь. У хорошего разработчика ответственности нет. Вы не ослышались. Ее нет, пусто, ноль, вакуум. Если ваш отличный разработчик говорит что вот я это сделаю за такой-то срок, само по себе это заявление бесполезно. Ведь если он не успеет, сделает не так, что то пойдет не так как ожидали, что вы будете делать? Штрафовать деньгами — проигрышный вариант, понижает мораль не только текущего разработчика но и всех остальных. Уволите? Вы же знаете, что человека который бы так разбирался в проекте больше нет. Что же делать?

Ответ прост. Никогда, ни при каких обстоятельствах не перекладывайте всю ответственность за выполнение задач на ваших разработчиков. Эту проблему решает тимлид. Как бы это не было больно для небольшой компании где каждый час разработчика на счету, когда у меня были стартапы с бюджетом в 5000 долларов в месяц, мне все равно приходилось иметь тимлида. Я полностью освобождаю тимлида от всех задач по разработке, хотя он всегда бывший разработчик, кто участвовал в запуске проекта как разработчик. Тимлид это наиболее психологически устойчивый, желательно семейный человек, которому есть что терять и который имеет авторитет в коллективе. Тимлидом должен быть человек, которому есть что терять если он уволиться, поэтому тимлид у меня получает относительно высокую ЗП и с ним я выстраиваю доверительные, партнерские отношения, скажем скататься по своим делам, заниматься своими вещами когда нет текущих задач это нормально.

Я не замечал в Западных компаниях, а вот у нас Ответственность и Отвечать за результат это немного разные вещи. Я очень уважаю своих разработчиков, они лучшие, но когда они дают срок, первое что я делаю я заставляю тимлида обязательно подписаться под каждой задачей и обсудить ее с разработчиком. Тимлид знает, что наши сроки влияют на доходность компании, он знает об ограничениях, у него есть опыт работы и поэтому он всегда просматривает все задачи и именно он отвечает за сроки и качество выполнения. Я не ругаю своих разработчиков, если мы видим что появляется проблема мы собираем общий чат где я, тимлид и разработчик обсуждают и решают проблему. Получается что ответственный за задачу разработчик, но отвечает за ее выполнение всегда тимлид. Теперь, если у нас возникает проблема, я не являюсь плохим парнем, и не наказываю никого, мы собираем чат и обсуждаем что будем делать, в 90% случаев это необходимость переработок со стороны разработчика и тимлида, и проблема решается, при этом решение предлагает либо сам тимлид, который на стороне разработчика, либо сам разработчик. В 10% случаев когда переработки не решают проблему, мы можем использовать комбинацию следующих моментов:

1. Тимлид и/или разработчик выезжают к клиенту, чтобы на месте добить систему и показать клиенту что о нем заботятся. Вы не поверите насколько это эффективное решение, даже если сроки уже вышли, вы просто приехали и работаете вместе с клиентом у него на площадке, вы часто можете получить более позитивный фидбек, чем если бы просто сдали проект в срок.
2. Разработчик просит других ребят из офиса, своих знакомых за пределами офиса, помочь в решение проблемы.
3. Мы принимаем проблему, получаем убыток, в следующем проекте напоминаем разработчику что нужно его сделать лучше, чтобы стереть наследие неспешного проекта.

Ключевой вывод: Обязательно фиксируйте ответственных и тех кто отвечает за сдачу задачу (не надо путать Responsible и Accountable, тут скорее две грани Accountable). Делите ответственность между разработчиком и тимлидом. Обязательно создавайте роль тимлида в команде, это ваша правая рука и адвокат разработчиков. Никогда не наказывайте тех людей, которых вы цените, цените то что они уже подписались сделать что то новое и интересное. Вместо этого, совместно с тимлидом и разработчиком решите как вы будете решать проблему. Если ваши разработчики не умеют брать на себя ответственность и не готовы совместно решать ее плохое исполнение, переводите их в тестеры или в джуниоры.

Продолжение следует…

Предыдущие статьи:

Жизнь управленца, кадр 1, не надейтесь на понимание
Жизнь управленца, кадр 2, жесткая воля
Жизнь управленца, кадр 3, коммуникации
Жизнь управленца, кадр 4, Планирование — Постановка задачи
Жизнь управленца, кадр 4-1, Планирование — Разбор задач
Жизнь управленца, 5, Управление изменениями

Автор: undry

Источник