Важность коммуникации в IT-сфере

Если вы рассматриваете себя в будущем в качестве руководителя, то саморазвитие и поглощения большого количества полезной информации должны стать неотъемлемой частью вашего времени. Эти книги будут полезны как практикующим руководителям, так и просто разработчикам, т. к. про развитие софт-скиллов тоже нельзя забывать!

Итак, поехали:

• "Как пасти котов" Дж. Ханк Рейнвотер. Наставление для программистов, руководящих другими программистами.

Здесь сразу привлекает аналогия программистов и котиков. Думаем, большинство наших коллег рекрутеров прекрасно чувствуют эту схожесть в процессе хантинга. Так как в процессе найма и адаптации участвует и руководитель разработки (Team lead или СТО), то важно понимать заранее как сделать команду единым целым и успешно им управлять.

Книга на самом деле про то, как выстроить внутри команды системность, гибкость и открытость, чтобы стать хорошим лидером. Но, чтобы им стать, необходимо овладеть собой и научиться выстраивать доверительные отношения с коллегами и со своим начальником.

• "Человеческий фактор: успешные проекты и команды" ДеМарко Том, Листер Тимоти.

Книга затрагивает уйму важных моментов, влияющих на динамику разработки. Мы решили выделить следующие интересные пункты:

1. Человеческий фактор.

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

2. Трудоголизм.

Некоторым управленцам кажется, что это большая ценность иметь в команде трудоголикам, ведь им чаще всего не важны сверхурочные и другие плюшки компании. Им важен результат. Но этот результат порой приводит к страшным потерям - выгорание, осознание всей бесмысленности из-за потери work-life balance и далее увольнение.

На нашей практике было много кейсов, когда невероятно сильные и опытные разработчики покидали проекты из-за выгорания и нестабильного ментального состояния. Подобные случаи лишь подтверждают то, что хорошо выстроенные процессы руководством не влекут за собой такие потери (хотя конечно исключения есть абсолютно везде). Здесь же важно со стороны тимлида или СТО проводить one-to-one, чтобы обсуждать продуктивность каждого разработчика в команде и следить за их состоянием.

3. Software productivity.

Объединили сразу несколько факторов, влияющих на производительность разработчиков, о которой вскользь упомянули выше. Каждый из них индивидуален и может по-разному сказываться на членах команды и это, опять же, важно обсуждать как при найме, так и при внешних изменениях в мире и политике.

Сюда входит и то, как обустроен офис (какие отделы работают в одном помещении, какие в нем проходят мероприятия), какой напарник по задаче тебе попался, в какое время комфортнее работать сотруднику и как часто/долго происходят созвоны, которые не позволяют сосредоточиться на коде.

4. Взаимозаменяемые винтики.

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

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

5. Культура.

Автор пишет больше про химию, но в наше время это стали чаще называть культурой компании. Культуры могут сильно различаться, если брать за примеры молодую компанию с духом стартапа и крупную компанию с большой историей. *Конечно некоторые по своему масштабу компании до сих пор могут удивлять своей классной культурой. Это может сильно мотивировать сотрудников, когда в приоритете руководства не сроки, а качество проделанной работы; не жесткий график, а возможность начать работу позже, но сделать ее с душой и в комфортное время суток; небольшие плюшки или хотя бы словесная похвала по итогам спринта, которая приносит удовлетворение; не жесткая бюрократия и регламенты, а возможность привнести свою идею и сделать даже лучше ожидаемого, ведь руководитель тебе доверяет.

Эти книги советуют многие управленцы из мира IT, поэтому берите на вооружение :)