Проработав почти 25 лет в ИТ, у меня накопилось то, о чём хотелось бы рассказать. Я изучил множество технологий, участвовал в массе проектов. Работал как в мелких фирмах, так и у мировых гигантов. Общался с разными людьми из разных стран и континентов. Основным моим мотивом всегда был успех проекта. Я всегда пытался сделать работу на максимуме своих возможностей. Много читал и изучал, анализировал, писал на разных языках и платформах. Всегда было стремление сделать проект как можно лучше. Но далеко не всегда это получалось. Когда давали возможность, что-то выходило, хотя не всегда. Иногда возникали обстоятельства, которые ставили крест на всей работе.

Причин, которые приводили проект к успеху или, наоборот, к провалу, всегда было немало. Анализируя свой опыт, у меня возник вопрос: а почему так получалось? Почему один проект выстрелил, а другой нет? Почему с одной командой мы буквально горы свернули, а с другой так ничего и не добились? Вспомнив все эти ситуации и проанализировав их, я написал две книги, в которых рассказываю о том, что может негативно повлиять на команду разработчиков и в итоге привести к провалу проекта, над которым они работают, либо к её распаду.

В книге «Лоу-перформеры в ИТ: кто тянет команду вниз» я рассказываю о сотрудниках, которые делают вид, что работают. С такими приходилось очень часто встречаться, и я пришёл к выводу, что они негативно влияют и на проект, в котором задействованы, и на команду, частью которой являются.

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

Вкратце, что это за типы:

Душа компании — весёлый и коммуникабельный сотрудник, который на работе хорошо проводит время вместо того, чтобы дело делать.
Хороший протеже — знакомый различных начальников или владельцев фирмы, который злоупотребляет связями и отлынивает от работы.
Критик-иллюзионист — человек, который, критикуя всех вокруг, создаёт ощущение своей важности, незаменимости и полезности. Но если разобраться, то это лишь тактика, чтобы поменьше работать и получше устроиться.
Теоретик-демагог — любитель долгих обсуждений и бесконечных разговоров. В итоге тратит и своё время, и время команды непонятно на что.
«Я знаю, как лучше и сделаю лучше» — перфекционист, который ради идеального кода готов проект сломать. В итоге работает с утра до ночи, а толку реального от него немного, скорее наоборот, больше проблем.
Умник. Начинает делать и ищет тех, кто бы за него доделал — сотрудник с философией: «Не хочешь работать сам — найди другого». Вроде бы и идеи хорошие предлагает, и начинает работу очень активно, но быстро «устает» и начинает искать помощников. Как итог, всё делают они, а не он.

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

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

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

Эта тема особенно важна для ИТ. С одной стороны, без конфликтов невозможно обойтись, с другой — они способны разрушить всё, и даже самая идеальная на первый взгляд команда может распасться в один миг. Уверен, многие истории, приведённые в книге, будут знакомы читателю: кто-то сталкивался с ними лично, кто-то видел или слышал о похожих случаях.

Итак, вкратце о конфликтах, описанных в книге:

Кондиционер — кому-то жарко, кому-то холодно. Казалось бы, мелочь, но именно такие ситуации встречаются часто и нередко становятся поводом для споров.
Истерика — один сотрудник срывается и кричит на коллегу в ответ на просьбу. Такое поведение не приносит пользы и требует вмешательства.
Традиции — корпоративные обычаи и ритуалы, которые нравятся не всем. Разные взгляды на них нередко становятся причиной конфликтов.
Конфликт полномочий — когда в команде появляются новые начальники при уже существующих старых. Руководителей становится больше, и между ними нередко вспыхивают стычки.
Соперничество — борьба между сотрудниками одинакового уровня за уважение и неформальное лидерство, которая может обернуться серьёзными конфликтами.
Молчание стоит дорого — истории о том, как страх показать сделанную работу и промежуточные результаты заказчику оборачивается серьёзными проблемами для компании.
Споры о подходах — типичная ситуация в ИТ, когда разработчики начинают спорить о том, как правильно писать код. Иногда такие, на первый взгляд безобидные, дискуссии перерастают в серьёзную проблему.
Ревью — при работе над проектом команда проводит ревью кода, когда один сотрудник проверяет работу другого. Естественно, в таких ситуациях нередко возникают конфликты.
Сроки — амбициозные обещания нередко становятся причиной конфликтов. Ошиблись в прогнозах или сознательно пообещали сделать всё слишком быстро — и не уложились. На этой почве легко возникают споры и напряжение.
Культурные и этнические различия — случаи, когда между сотрудниками возникают трения из-за особенностей их культуры или национальности. Мне доводилось сталкиваться с такими ситуациями, и нередко конфликты вспыхивали буквально на пустом месте.
Между двух огней — истории о том, как разные пожелания высшего руководства приводят к серьёзным проблемам в команде и проекте. Такая ситуация может стать причиной конфликта.

Как и предыдущая книга, эта написана с позиции руководителя команды разработки, но будет полезна самому широкому кругу читателей. В ней речь идёт не только о конфликтах, но и о способах их разрешения. Я делюсь не только собственным опытом, но и тем, какие решения предлагают авторы известных книг и публикаций по этой теме.

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

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

И, конечно, это не все проблемы, с которыми сталкивается руководитель команды разработки. В этих двух книгах я подробно остановился лишь на двух из них — лоу-перформерах и конфликтах. Но на практике проблем, с которыми приходится иметь дело руководителю, гораздо больше.

Буду рад новым читателям и открыт к общению. Если окажусь полезен советом или опытом — с удовольствием поделюсь. А если будет возможность — готов лично помочь в решении сложных ситуаций в командах разработки программного обеспечения.

Две книги о проблемах ИТ-команд