Книги августа. Об управлении в сфере разработки ПО

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

1. Тим Листер, Том ДеМарко — «Человеческий фактор. Успешные проекты и команды»

Это единственная книга из списка, выбивающаяся тем, что прочитал я её ещё пять лет назад. И хоть я с тех пор пять лет не имел отношения к разработке ПО, эта книга стала для меня одной из самых ценных и полезных. Считаю, что для любого менеджера это must read. А если вы ещё и ИТ менеджер, а то вдруг и в области разработки, то просто стыдно должно быть, если вы о ней хотя бы не слышали. Также повлияло то, что большинство книг, перечисленных ниже, ссылаются на эту.

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

Основные идеи и выводы из данной книги находят сейчас своё применение в agile-методологиях. Учитывая, что первое издание Peopleware вышло где-то в в 80-е годы прошлого века, «новизна» гибких методологий не может не вызывать усмешку. Особенно с учётом того, что реализовывать фактически их пытаются именно без учёта именно этих главных идей.

2. Тим Листер, Том ДеМарко — «Вальсируя с медведями»

После «Человеческого фактора» и «Романа об управлении проектами», у этих авторов хочется читать всё. Мало кто ещё способен подавать материал столь ёмко, легко и увлекательно.

Как известно, объявление нежелательного события немыслимым не делает его невозможным. Но это делает практически невозможным управление рисками.

Данная книга — о такой небольшой, часто упускаемой из виду, но очень важной части общей области управления проектами, как управление рисками.

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

Тактика, присущая управлению риском, состоит в том, чтобы слушать каждое свое произнесение слов «я не знаю» (вслух или мысленно) и всякий раз принуждать себя задавать вспомогательный вопрос:
Что я знаю (или что я мог бы знать) о том, чего я не знаю?

3. Стеллман, Грин — «Идеальные команды. Вдохновляющие и предостерегающие рассказы ветеранов тимлидинга»

Две с половиной тысячи лет назад Лао Цзы сказал: когда людьми управляет лучший из руководителей, они говорят, что все сделали сами.

Данная книга не столько учебная литература, сколько сборник разнообразных историй с элементами интервью, разбитый на блоки по темам — Люди, Цели, Методы и Препятствия. В которых управленцы, техлиды и разработчики рассказывали о своём опыте. Разные компании, разные проекты, разное время (от 80-х до 2000-х.

«Как ты думаешь, где будешь слушать свою музыку через 10 лет?» – Майкл Робертсон, исполнительный директор MP3.com.
«В тюрьме», – Кристофер Джайлс, инженер-программист и скрипач.

Несмотря на большой объём, прочиталось на одном дыхании. Местами очень эмоционально. Далеко не все истории — success story, и этим они становятся ещё более познавательными и поучительными.

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

Несколько ночей меня мучила бессонница, так что я приходил в офис довольно рано. Проект был нервный, и однажды я пришел совсем рано – около пяти часов утра. И вот в пять утра я встречаю там двух главных программистов второго проекта, Джеффа и Донну.
Я спросил: «Ребята, что вы тут делаете?» Сначала они не хотели отвечать. Но в конце концов сознались: «Мы добавляем обработку ошибок и тестируем. Босс запретил нам делать это в приложении, но совесть нам не позволяет. Мы не можем выпустить программу в таком виде, как он требует».
Все три последних месяца они приходили в пять утра и работали до семи. В семь они шли в бар позавтракать. С семи до восьми они ели и к восьми возвращались на работу, притворяясь, будто только что пришли! Потом они до пяти или шести вечера работали над своим приложением.

 

4. Эдвард Йордан — «Путь камикадзе (Смертельный марш)»

Хотя такие формы обучения выглядят разумными и рациональными, во многих небольших организациях они игнорируются; обучение проводится непосредственно во время работы, разработчикам приходится вникать в тонкости процессов и средств по ходу дела. Ещё хуже дело обстоит для менеджеров — как заметил мой приятель Tim Lister, единственное обучение, которое получает большинство менеджеров проектов, заключается в двух словах: «Желаю удачи!»

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

Книга о том, что вы можете сделать, если вы — менеджер подобного проекта.

Каждый командующий армией, обязанный выполнять план, который он считает порочным, должен отстаивать свои доводы и требовать изменения плана, и, в конце концов, должен скорее подать в отставку, чем послужить причиной поражения своей армии.

— Наполеон 

В части увлекательности, ёмкости и доступности изложения Йордан не отстаёт от Листера и ДеМарко. А если и отстаёт где-то, это это щедро компенсируется хорошим юмором.

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

 

5. Гойко Аджич — Impact mapping

Очень маленькая, но очень полезная книжка для любого, кто развивает какую-то систему, продукт или команду.

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

Impact Mapping — это подход формирования целей и способов их достижения с сохранением фокуса и предотвращением растягивания границ. Представляет собой ответ на четыре вопроса:

• Зачем?
• Кто?
• Что?
• Как?

представленный в виде майнд-карты.

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

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

 

6. Рейнвотер — «Как пасти котов. Наставление для программистов, руководящих другими программистами»

Правды нет – о ней нам только рассказывают.
Анонимный автор с Юга

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

Правда ли, что настоящие руководители ходят в черном? Некоторые – ходят. Иные даже носят на голове хвосты (хотя это, конечно, зависит от того, сколько у них осталось волос). Так они пытаются повысить свой авторитет в глазах подчиненных им придурков или «ботаников» – выберите тот эпитет, который вам больше нравится. Вполне возможно, вам не нравятся оба варианта, а себя вы ощущаете руководителем современного типа, организующим подобных вам специалистов, которые искренне считают программирование пищей для ума. Что я хочу сказать? Стереотипы (в том числе упомянутые в заголовке раздела) не следует воспринимать слишком серьезно. О чем действительно стоит задуматься, так это о личных взаимоотношениях с программистами и своем месте среди них.

Эту книгу я не дочитал, т.к. несмотря на общую увлекательность и дозы позитива, несёт уже мало нового для меня, а на очереди много более актуального чтива.

Жаль, что она не попалась мне лет 8-10 назад.

Все эти и немножко других книг можно взять почитать из моей коробки. Не забудьте вернуть :)