Три правила руководства айтишниками | Большие Идеи

・ Операционное управление

Три правила
руководства айтишниками

Разработчики — это не менеджеры, они творцы, такие же как дизайнеры или модельеры, и руководить ими надо по-другому.

Автор: Сергей Рыжиков

читайте также

Рецепт инноваций: модель Agile

Даррелл Ригби,  Джефф Сазерленд,  Такеучи Хиротака

Шесть ошибок при выходе на международные рынки

Натали Келли

«Умные» KPI: маленькие шаги на пути к общей цели

Дэвид Кирон ,  Майкл Чу ,  Майкл Шрейг ,  Франсуа Канделон,  Шервин Кодобенда

Жертвы алгоритмов: что не так с интернет-маркетингом

Алекс Миллер,  Картик Хосанагар

Разработчики — это не менеджеры, они творцы, такие же как дизайнеры или модельеры, и руководить ими надо по-другому. Если владелец бизнеса не будет этого учитывать в организации их труда, то его ИТ-отдел будет выдавать неинтересный и нежизнеспособный продукт.

Выберите метод работы

Есть два метода работы с командой разработчиков: «прорабский» и «сдельщина». Наем внешних айтишников с почасовой оплатой — это «сдельщина». Главное преимущество этого метода — скорость.

Но режим «прорабского» управления — наиболее продуктивный. Суть метода в том, чтобы нанять хорошего технического директора, который будет выполнять роль квалифицированного прораба, а команда может быть как внутренней (что бывает чаще всего), так и внешней. Но этот метод не работает в крупных коллективах. У нас в штате около 100 человек, и мы предпочли использовать «прорабский» метод и справляемся.

Возьмите контроль в свои руки

До начала разработки очень важно создать атмосферу, в которой все участники проекта, включая исполнителей, смогут высказаться по поводу плюсов и минусов продукта. Чем больше дискуссий, тем лучше, но в какой-то момент «прораб», ответственный за проект, должен будет подвести черту и зафиксировать все рациональные идеи.

Главный враг любого ИТ-продукта — затягивание сроков. Разработчики искренне не понимают, почему нельзя тратить больше времени, чтобы сделать продукт лучше. Результат не побуждает программиста к свершениям, ему больше интересен процесс профессионального роста. Когда я сам был программистом в банке, то использовал не самые эффективные способы работы, а новые и, как мне тогда казалось, профессиональные методы. Признаюсь, я тогда просто учился за счет банка.

В итоге я придумал, как можно бороться с затягиванием сроков. Скажем, можно организовать встречу с командой за полгода до релиза продукта и сказать ей, что ровно через шесть месяцев будет презентация продукта, под нее зарезервирован бизнес-центр и уже анонсирована онлайн-трансляция.

Можно придумать все что угодно: например, сказать, что готовый результат мы представим совету директоров или вообще президенту России. Главное — дать айтишникам понять, что перенос просто невозможен. В противном случае «жизнь займет все предоставленное ей пространство», а программисты — все выделенное им время, а то и в два раза больше.

Еще один важный момент: работу над проектом нужно разделить на этапы, длительностью по 3—4 месяца. И каждый из них должен обязательно заканчиваться тестированием: нужно показать продукт фокус-группе. Когда мы запускали бета-версию «Битрикс24», то первые три месяца ею пользовались только 500 партнеров нашей фирмы.

Демонстрируйте искренний интерес

Недавно разработчик показывал мне новую опцию для одного из наших продуктов — «Корпоративного портала». Она была сделана хорошо, но было не понятно, как ей пользоваться. Я описал ему собирательный образ «менеджера отдела рекламы Марины», девушки-гуманитария, крайне далекой от ИТ-тематики, и сказал: «Сделай так, чтобы Марине было понятно». В итоге опция была доведена до ума и стала понятной для простых пользователей.

Если вы заказчик, то тесное общение с разработчиками полезно не только потому, что оно возвращает их на землю. Это не столько контроль, сколько проявление внимания. Они видят заинтересованность наверху и понимают, что не зря тратят свои силы. Можно подсесть к разработчику и спросить, что у него получается. Руководителю будет интересно узнать, как идут дела, а айтишникам — об этом рассказать.

Помимо прочего, чтобы и управленцам, и разработчикам было легче найти общий язык, хорошо иметь общие принципы подхода к работе. У нас в компании есть свой набор понятных для всех ценностей. Мы не рассказываем о них за пределами фирмы. Они похожи на Agile-манифест (свод правил, придуманный ведущими разработчиками США 12 лет назад). Присмотритесь к нему, когда решите создать свою собственную корпоративную культуру.