Никколо Макиавелли в руководстве для эффективного менеджера написал: «Как художнику, когда он рисует пейзаж, надо спуститься в долину, чтобы охватить взглядом холмы и горы, и подняться в гору, чтобы охватить взглядом долину, так и здесь: чтобы постигнуть сущность народа, надо быть государем, а чтобы постигнуть природу государей, надо принадлежать к народу». Думаю, что в соответствии с наблюдением итальянского мыслителя, любой, кто проходит путь от программиста до руководителя компании, собирает целую коллекцию типичных проблем менеджеров и разработчиков. В этой статье хочу поделиться своими наблюдениями. Сразу отмечу, что все приведенные ошибки были совершены мною лично, а некоторые даже по несколько раз. Любые совпадения неслучайны: все мы люди.
Известный консультант по менеджменту Ицхак Адизес сравнивает организацию с цепью взаимосвязанных шестеренок, в которой руководитель представляет собой большую шестеренку, а его подчиненные являются шестеренками меньших размеров. Небольшое движение большой шестеренки, может вызвать несколько оборотов маленьких. Если руководителем является человек, у которого «семь пятниц на неделе», то его сотрудники очень быстро устанут от его постоянных метаний и начнут руководствоваться принципом «не спеши выполнять приказ — отменят», и организация превращается в вязкое болото. У руководителя должно быть четкое видение целей и задач, ну и, конечно, воля для их достижения.
«Вчера попробовал на своих подчинённых метод кнута и пряника. Пряник неудобен — крошится при ударе. Надо опробовать метод кнута и кнута». К сожалению, иногда эта шутка превращается в устойчивый поведенческий шаблон руководителя. Сотрудник выполняет все свои задачи и даже больше, а его не замечают, хорошая работа воспринимается как должное, а любая ошибка считается критическим провалом. Такая модель поведения очень сильно бьет по мотивации специалиста и негативно действует на весь коллектив в целом. Сотрудники начинают руководствоваться принципом «Поближе к кухне, подальше от начальства». Руководителям необходимо учиться видеть результаты работы и успехи сотрудников и поощрять их достижения.
С друзьями хорошо пить в баре пиво и обсуждать новости ИТ-индустрии, а вот вести бизнес может быть проблематично. Друзья руководителя в какой-то момент могут решить, что они вне установленных правил. Может появиться зависть, желание использовать дружбу в своих интересах и в ущерб общему делу. Руководитель должен четко разделять личные и рабочие отношения. Лучше дружба, построенная на бизнесе, чем бизнес на дружбе.
Менеджмент связан с конфликтами. Когда руководитель старается быть хорошим для всех, это может привести к тому, что в коллективе появляются бездельники, которых он не может уволить. Причина – угроза истерик, слез, рассказов о тяжелой жизненной ситуации, а иногда и шантаж. Встречаются ситуации, когда сотрудник откровенно «забивает» на работу, но при угрозе увольнения «вспоминает», что у него, оказывается, сидит дома требовательная жена и дети, которых надо кормить, а летом обязательно вывезти на месяц-два к теплому морю. Почему осознание своей личной ответственности не приходит в те моменты, когда он начинает «подваливать» на работу к часу дня или включать развлекательные ролики на YouTube в рабочее время? Если руководитель допускает подобное поведение в своей команде, то эффективность работы остальных сотрудников начинает снижаться, так как люди задаются вопросом: «А что, так, оказывается, можно было?». С бездельниками нужно уметь расставаться быстро и без лишних сантиментов, они должны работать у наших конкурентов.
В середине нулевых я участвовал в проекте по разработке системы для управления запасами для одной американской фармацевтической компании. У проекта была плохая предыстория: заказчик самостоятельно описал требования, а наш менеджер проекта радостно согласился убрать из проекта фазу сбора и анализа требований. Соответственно, когда дело дошло до реализации, стали всплывать неприятные сюрпризы: противоречия в требованиях, неясности, явные ошибки, и сроки проекта «поплыли». Менеджер принял волевое решение: «Будем работать по субботам!». Решение мы выполнили и стали работать в офисе по выходным, но самого менеджера в те дни не увидели. Наше отношение к руководителю резко ухудшилось, что сказалось и на результативности нашего труда. Если руководитель хочет сподвигнуть сотрудников на переработку и трудовые подвиги, то и сам должен проявить себя и не забыть про мотивацию своих сотрудников.
Чем выше сотрудник поднимается по карьерной лестнице, тем больше места в его жизни занимают всевозможные совещания. Известно, что совещания могут иметь разные виды и проходить в разных форматах. Совещания могут быть:
С форматами совещания тоже все знакомы:
К совещаниям необходимо готовиться, управлять их ходом и обеспечивать выполнение принятых на них решений. Если руководитель допускает смешивание видов и форматов совещаний, пускает все на самотек, то вместо решения проблем он добивается только их «проговаривания». Кстати, стали попадаться резюме специалистов, в которых в числе ключевых своих навыков включено участие в совещаниях, возможно, кандидаты подразумевают, что научились спать с открытыми глазами.
Если руководитель занял свое место, но при этом не прошел путь с низов карьерной лестницы, то есть риск, что не все процессы, которыми он пытается управлять, для него прозрачны. В этом случае он становится заложником своих подчиненных, которые могут ему годами рассказывать про нерешаемые задачи и космические сроки. Руководитель должен уметь вникнуть в суть проблемы и при необходимости погрузиться даже до низкоуровневых деталей, например, посмотреть на реализацию алгоритма в продукте, который создает его компания.
По отношению к результатам своего труда на одной стороне спектра можно разместить специалистов, которые делают все на «отвяжись», а на другой стороне – перфекционистов, которые никогда не могут закончить работу из-за своего маниакального стремления к недостижимому идеалу. Разработчик-профессионал должен находиться где-то посередине и создавать код, в котором он сам уверен, так как протестировал корректность его работы еще до передачи специалистам по тестированию. В особо тяжелых случаях тестирование проводится заказчиками за их же собственные деньги. На мой взгляд, любой сотрудник компании прежде, чем передать результаты своей работы, должен самостоятельно убедиться в уровне ее качества и не рассчитывать на то, что за ним проверит кто-то другой.
Есть старый студенческий анекдот.
Решили провести опрос среди студентов.
У американского спрашивают:
— За сколько вы выучите китайский язык и сдадите по нему экзамен?
— Ну это очень трудный язык… Года за два осилю.
Тот же вопрос задают англичанину:
— Если на четверку, то где-то за год. А на пятерку не сдам никогда.
Спросили у студента МГТУ им. Н.Э.Баумана, тот отвечает:
— Методичка есть?
— Есть.
— Сейчас докурю, пойду сдавать.
Сейчас у любого разработчика есть неограниченный доступ к документации, к opensource-проектам, в которых уже скорее всего решены те проблемы, с которыми он столкнулся в своей работе. Тем не менее есть люди, которые, встретив первые трудности, сдаются, так и не найдя решения в поисковике. Хороший разработчик должен уметь пользоваться Google, формулировать мысли на английском и не бояться заглянуть в чужой код на GitHub.
Будучи старшекурсником, проходил стажировку в компании, специализирующейся на разработке ПО, в ходе которой в первый раз услышал о стандартной проблеме программистов, актуальной до сих пор. Разработчикам всегда интересны новые технологии и чистое творчество. Вместо того, чтобы преступить к решению конкретной задачи, которая необходима заказчику, мы начинаем создавать свой фреймворк, с помощью которого, как мы думаем, потом можно будет решить любую задачу заказчика. В итоге на решение тех проблем, за которые нам платят деньги, мы оставляем совсем немного времени проекта, и качество продукта начинает страдать. Нужно уметь решать не всевозможные проблемы, а решать те задачи, которые действительно важны для пользователей наших продуктов, ну и, конечно, изначально закладывать возможность безболезненного расширения функционала. Если же хочется почувствовать себя творцом фреймворка, то масса opensource-проектов ждут нас в свободное от работы время.
Программист, на мой взгляд, это человек, который во всем видит структуры данных и алгоритмы и любит находить решения проблем. Тем не менее, иногда в нашей профессии оказываются люди, для которых чрезвычайно сложно структурировать информацию, видеть зависимости, находить решения. Некоторые вместо поиска решения радостно придумывают десяток нерешаемых проблем. Профессионал должен постоянно работать над собой и изучать соответствующую литературу, которая позволит ему превратиться в структурированного problem solver’а.
На упоминавшейся выше стажировке руководитель центра подготовки нам рассказывал еще про один стандартный путь разработки. Стартует проект и его сначала ведет всего лишь один разработчик-профи, который все делает сам и все держит у себя в голове. Затем у него появляются программисты-помощники, которые выполняют только его указания. При этом из-за отсутствия документации, так как у нашего профи отсутствует желание делиться своими сакральными знаниями, помощники не знают, как устроен и как функционирует продукт. Получается продукт одного человека. Затем решение выводят на рынок, пользователи начинают его эксплуатировать и находят ошибки. Проблемы может решать только профи, и теперь его работа превращается из свободного творчества в кошмар. Ему это надоедает, и он уходит на другой проект в другую компанию и слышать больше не хочет о своем детище. «Счастливые» пользователи остаются с неподдерживаемым решением. Только полноценное документирование разработки и обмен знаниями в команде позволяет избежать такой печальной ситуации. Сейчас компании активно внедряют процессы безопасной разработки, которые в том числе подразумевают и подробное документирование проекта. Кстати, ГОСТ Р 56939-2016 «Защита информации. Разработка безопасного программного обеспечения. Общие требования» был разработан экспертами нашей компании.
Профессионалы любят свою работу и гордятся своим кодом. Непрофессионалы могут считать, что пользователи и так будут пользоваться их продуктом, например, из-за отсутствия доступных альтернатив. Отличительной чертой таких компаний-вендоров является нежелание пользоваться своими разработками внутри компании. На мой взгляд, если программист не горит продуктом, который он создает, не уважает его пользователей, то ему стоит задуматься о смене сферы приложения его усилий. Тем самым он облегчит жизнь и себе, и множеству клиентов компании-работодателя.
Многие ИТ-специалисты не всегда бывают общительными, из-за чего могут и незаслуженно пострадать. Перейдя из разработки в ИТ-консалтинг, я усердно трудился, чтобы выделиться среди своих коллег и получить двойное повышение (перепрыгнуть через ступеньку в карьерной лестнице). Даже с первого раза сдал профессиональные экзамены CISA, CISSP, которые должны были сдавать только специалисты, имеющие опыт на пару лет больше, чем у меня. Когда же пришли письма о назначениях, я с удивлением обнаружил, что меня повысили также как и остальных – на одну ступень. Тогда я наконец-то набрался смелости и задал вопрос своему руководителю о повышении, на что получил простой ответ: «Да, ты прекрасно работаешь, но ты же ни разу не сказал о своей цели получить двойное повышение». Нужно не бояться общаться как с коллегами, так и с руководителями, окружающие люди должны знать о том, что у вас в голове. Даже если разработчик близок к гениальности, но при этом не умеет общаться с коллегами или даже «токсичен» (негативист), то пользы от него большой не будет, а вот портить жизнь всей команде он сможет. Коммуникативные навыки в современном мире очень просто развить и этой возможностью нельзя пренебрегать.
Как руководители должны разбираться в тех процессах, которыми они управляют, так и программисты должны понимать предметную область, в которой они работают. Что такое по своей сути программирование? Создание алгоритмов и структур данных, отражающих предметную область. Если вы не понимаете, что вы делаете, и как ваша программа облегчает жизнь пользователям, хороший продукт вы создать не сможете.
Тема статьи, конечно, обширная и ее невозможно ограничить несколькими наболевшими моментами, о которых получилось написать. Известные авторы пишут об этом целые книги. Из прочитанного хочется порекомендовать две: «Идеальный руководитель. Почему им нельзя стать и что из этого следует» Ицхака Адизеса и «Идеальный программист. Как стать профессионалом разработки ПО» Роберта Мартина. Также добавлю, что прямо сейчас мы расширяем департамент разработки в нашей компании «Эшелон Технологии» (входит в группу компаний «Эшелон»), и активно ищем талантливых разработчиков разного уровня, которые разделяют наши взгляды на жизнь и работу.
Советы руководителям от сотрудников
1. Определите цели и задачи и постарайтесь их не менять каждый день.
Известный консультант по менеджменту Ицхак Адизес сравнивает организацию с цепью взаимосвязанных шестеренок, в которой руководитель представляет собой большую шестеренку, а его подчиненные являются шестеренками меньших размеров. Небольшое движение большой шестеренки, может вызвать несколько оборотов маленьких. Если руководителем является человек, у которого «семь пятниц на неделе», то его сотрудники очень быстро устанут от его постоянных метаний и начнут руководствоваться принципом «не спеши выполнять приказ — отменят», и организация превращается в вязкое болото. У руководителя должно быть четкое видение целей и задач, ну и, конечно, воля для их достижения.
2. Не демотивируйте!
«Вчера попробовал на своих подчинённых метод кнута и пряника. Пряник неудобен — крошится при ударе. Надо опробовать метод кнута и кнута». К сожалению, иногда эта шутка превращается в устойчивый поведенческий шаблон руководителя. Сотрудник выполняет все свои задачи и даже больше, а его не замечают, хорошая работа воспринимается как должное, а любая ошибка считается критическим провалом. Такая модель поведения очень сильно бьет по мотивации специалиста и негативно действует на весь коллектив в целом. Сотрудники начинают руководствоваться принципом «Поближе к кухне, подальше от начальства». Руководителям необходимо учиться видеть результаты работы и успехи сотрудников и поощрять их достижения.
3. Держите друзей подальше от бизнеса
С друзьями хорошо пить в баре пиво и обсуждать новости ИТ-индустрии, а вот вести бизнес может быть проблематично. Друзья руководителя в какой-то момент могут решить, что они вне установленных правил. Может появиться зависть, желание использовать дружбу в своих интересах и в ущерб общему делу. Руководитель должен четко разделять личные и рабочие отношения. Лучше дружба, построенная на бизнесе, чем бизнес на дружбе.
4.Не будьте тряпкой, увольняйте бездельников
Менеджмент связан с конфликтами. Когда руководитель старается быть хорошим для всех, это может привести к тому, что в коллективе появляются бездельники, которых он не может уволить. Причина – угроза истерик, слез, рассказов о тяжелой жизненной ситуации, а иногда и шантаж. Встречаются ситуации, когда сотрудник откровенно «забивает» на работу, но при угрозе увольнения «вспоминает», что у него, оказывается, сидит дома требовательная жена и дети, которых надо кормить, а летом обязательно вывезти на месяц-два к теплому морю. Почему осознание своей личной ответственности не приходит в те моменты, когда он начинает «подваливать» на работу к часу дня или включать развлекательные ролики на YouTube в рабочее время? Если руководитель допускает подобное поведение в своей команде, то эффективность работы остальных сотрудников начинает снижаться, так как люди задаются вопросом: «А что, так, оказывается, можно было?». С бездельниками нужно уметь расставаться быстро и без лишних сантиментов, они должны работать у наших конкурентов.
5. Если требуете от сотрудников переработку, то возглавьте ее!
В середине нулевых я участвовал в проекте по разработке системы для управления запасами для одной американской фармацевтической компании. У проекта была плохая предыстория: заказчик самостоятельно описал требования, а наш менеджер проекта радостно согласился убрать из проекта фазу сбора и анализа требований. Соответственно, когда дело дошло до реализации, стали всплывать неприятные сюрпризы: противоречия в требованиях, неясности, явные ошибки, и сроки проекта «поплыли». Менеджер принял волевое решение: «Будем работать по субботам!». Решение мы выполнили и стали работать в офисе по выходным, но самого менеджера в те дни не увидели. Наше отношение к руководителю резко ухудшилось, что сказалось и на результативности нашего труда. Если руководитель хочет сподвигнуть сотрудников на переработку и трудовые подвиги, то и сам должен проявить себя и не забыть про мотивацию своих сотрудников.
6.Научитесь проводить совещания
Чем выше сотрудник поднимается по карьерной лестнице, тем больше места в его жизни занимают всевозможные совещания. Известно, что совещания могут иметь разные виды и проходить в разных форматах. Совещания могут быть:
- оперативными (вопросы: «Кто/что делает? Какие результаты/проблемы? Какие планы?»);
- системными (вопросы: «Как наладить данный процесс и убрать в нем бардак?»);
- стратегическими (вопрос: «Какие наши цели и задачи?»);
- идеологическими (вопросы: «Для чего мы все это делаем?»).
С форматами совещания тоже все знакомы:
- обмен мнениями (каждый говорит по очереди);
- доклад (один выступает с презентацией/отчетом);
- обсуждение (любой может взять слово);
- мозговой штурм (хаотичная генерация идей с полным запретом критики).
К совещаниям необходимо готовиться, управлять их ходом и обеспечивать выполнение принятых на них решений. Если руководитель допускает смешивание видов и форматов совещаний, пускает все на самотек, то вместо решения проблем он добивается только их «проговаривания». Кстати, стали попадаться резюме специалистов, в которых в числе ключевых своих навыков включено участие в совещаниях, возможно, кандидаты подразумевают, что научились спать с открытыми глазами.
7. Разбирайтесь в том, чем вы руководите!
Если руководитель занял свое место, но при этом не прошел путь с низов карьерной лестницы, то есть риск, что не все процессы, которыми он пытается управлять, для него прозрачны. В этом случае он становится заложником своих подчиненных, которые могут ему годами рассказывать про нерешаемые задачи и космические сроки. Руководитель должен уметь вникнуть в суть проблемы и при необходимости погрузиться даже до низкоуровневых деталей, например, посмотреть на реализацию алгоритма в продукте, который создает его компания.
Советы сотрудникам от руководителей
1. Проверяйте за собой!
По отношению к результатам своего труда на одной стороне спектра можно разместить специалистов, которые делают все на «отвяжись», а на другой стороне – перфекционистов, которые никогда не могут закончить работу из-за своего маниакального стремления к недостижимому идеалу. Разработчик-профессионал должен находиться где-то посередине и создавать код, в котором он сам уверен, так как протестировал корректность его работы еще до передачи специалистам по тестированию. В особо тяжелых случаях тестирование проводится заказчиками за их же собственные деньги. На мой взгляд, любой сотрудник компании прежде, чем передать результаты своей работы, должен самостоятельно убедиться в уровне ее качества и не рассчитывать на то, что за ним проверит кто-то другой.
2. Ask Google first!
Есть старый студенческий анекдот.
Решили провести опрос среди студентов.
У американского спрашивают:
— За сколько вы выучите китайский язык и сдадите по нему экзамен?
— Ну это очень трудный язык… Года за два осилю.
Тот же вопрос задают англичанину:
— Если на четверку, то где-то за год. А на пятерку не сдам никогда.
Спросили у студента МГТУ им. Н.Э.Баумана, тот отвечает:
— Методичка есть?
— Есть.
— Сейчас докурю, пойду сдавать.
Сейчас у любого разработчика есть неограниченный доступ к документации, к opensource-проектам, в которых уже скорее всего решены те проблемы, с которыми он столкнулся в своей работе. Тем не менее есть люди, которые, встретив первые трудности, сдаются, так и не найдя решения в поисковике. Хороший разработчик должен уметь пользоваться Google, формулировать мысли на английском и не бояться заглянуть в чужой код на GitHub.
3. Не тратьте все время на создание фреймворка вместо выполнения задач
Будучи старшекурсником, проходил стажировку в компании, специализирующейся на разработке ПО, в ходе которой в первый раз услышал о стандартной проблеме программистов, актуальной до сих пор. Разработчикам всегда интересны новые технологии и чистое творчество. Вместо того, чтобы преступить к решению конкретной задачи, которая необходима заказчику, мы начинаем создавать свой фреймворк, с помощью которого, как мы думаем, потом можно будет решить любую задачу заказчика. В итоге на решение тех проблем, за которые нам платят деньги, мы оставляем совсем немного времени проекта, и качество продукта начинает страдать. Нужно уметь решать не всевозможные проблемы, а решать те задачи, которые действительно важны для пользователей наших продуктов, ну и, конечно, изначально закладывать возможность безболезненного расширения функционала. Если же хочется почувствовать себя творцом фреймворка, то масса opensource-проектов ждут нас в свободное от работы время.
4. Учитесь структурировать!
Программист, на мой взгляд, это человек, который во всем видит структуры данных и алгоритмы и любит находить решения проблем. Тем не менее, иногда в нашей профессии оказываются люди, для которых чрезвычайно сложно структурировать информацию, видеть зависимости, находить решения. Некоторые вместо поиска решения радостно придумывают десяток нерешаемых проблем. Профессионал должен постоянно работать над собой и изучать соответствующую литературу, которая позволит ему превратиться в структурированного problem solver’а.
5. Не старайтесь стать незаменимыми! Документируйте!
На упоминавшейся выше стажировке руководитель центра подготовки нам рассказывал еще про один стандартный путь разработки. Стартует проект и его сначала ведет всего лишь один разработчик-профи, который все делает сам и все держит у себя в голове. Затем у него появляются программисты-помощники, которые выполняют только его указания. При этом из-за отсутствия документации, так как у нашего профи отсутствует желание делиться своими сакральными знаниями, помощники не знают, как устроен и как функционирует продукт. Получается продукт одного человека. Затем решение выводят на рынок, пользователи начинают его эксплуатировать и находят ошибки. Проблемы может решать только профи, и теперь его работа превращается из свободного творчества в кошмар. Ему это надоедает, и он уходит на другой проект в другую компанию и слышать больше не хочет о своем детище. «Счастливые» пользователи остаются с неподдерживаемым решением. Только полноценное документирование разработки и обмен знаниями в команде позволяет избежать такой печальной ситуации. Сейчас компании активно внедряют процессы безопасной разработки, которые в том числе подразумевают и подробное документирование проекта. Кстати, ГОСТ Р 56939-2016 «Защита информации. Разработка безопасного программного обеспечения. Общие требования» был разработан экспертами нашей компании.
6. Полюбите свой продукт!
Профессионалы любят свою работу и гордятся своим кодом. Непрофессионалы могут считать, что пользователи и так будут пользоваться их продуктом, например, из-за отсутствия доступных альтернатив. Отличительной чертой таких компаний-вендоров является нежелание пользоваться своими разработками внутри компании. На мой взгляд, если программист не горит продуктом, который он создает, не уважает его пользователей, то ему стоит задуматься о смене сферы приложения его усилий. Тем самым он облегчит жизнь и себе, и множеству клиентов компании-работодателя.
7. Будьте позитивы и открыты для общения
Многие ИТ-специалисты не всегда бывают общительными, из-за чего могут и незаслуженно пострадать. Перейдя из разработки в ИТ-консалтинг, я усердно трудился, чтобы выделиться среди своих коллег и получить двойное повышение (перепрыгнуть через ступеньку в карьерной лестнице). Даже с первого раза сдал профессиональные экзамены CISA, CISSP, которые должны были сдавать только специалисты, имеющие опыт на пару лет больше, чем у меня. Когда же пришли письма о назначениях, я с удивлением обнаружил, что меня повысили также как и остальных – на одну ступень. Тогда я наконец-то набрался смелости и задал вопрос своему руководителю о повышении, на что получил простой ответ: «Да, ты прекрасно работаешь, но ты же ни разу не сказал о своей цели получить двойное повышение». Нужно не бояться общаться как с коллегами, так и с руководителями, окружающие люди должны знать о том, что у вас в голове. Даже если разработчик близок к гениальности, но при этом не умеет общаться с коллегами или даже «токсичен» (негативист), то пользы от него большой не будет, а вот портить жизнь всей команде он сможет. Коммуникативные навыки в современном мире очень просто развить и этой возможностью нельзя пренебрегать.
8. Разбирайтесь в том, что вы программируете!
Как руководители должны разбираться в тех процессах, которыми они управляют, так и программисты должны понимать предметную область, в которой они работают. Что такое по своей сути программирование? Создание алгоритмов и структур данных, отражающих предметную область. Если вы не понимаете, что вы делаете, и как ваша программа облегчает жизнь пользователям, хороший продукт вы создать не сможете.
Вместо заключения
Тема статьи, конечно, обширная и ее невозможно ограничить несколькими наболевшими моментами, о которых получилось написать. Известные авторы пишут об этом целые книги. Из прочитанного хочется порекомендовать две: «Идеальный руководитель. Почему им нельзя стать и что из этого следует» Ицхака Адизеса и «Идеальный программист. Как стать профессионалом разработки ПО» Роберта Мартина. Также добавлю, что прямо сейчас мы расширяем департамент разработки в нашей компании «Эшелон Технологии» (входит в группу компаний «Эшелон»), и активно ищем талантливых разработчиков разного уровня, которые разделяют наши взгляды на жизнь и работу.
