(Краткая рецензия на книгу «Peopleware»)

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

Ещё одна подобная идея состоит в концепции построения успешных команд, описанная Томом Демарко и Тимоти Листером в книге «Человеческий фактор» («Peopleware» by Tom DeMarco and Timothy Lister). К идее, что человек является главным звеном в процессе интеллектуальной деятельности, и, в частности, в процессе разработки ПО, необходимо придти именно эволюционным путём. Углубляясь по пути в тонкости методики разработки, совершенствование метрик и процессов тестирования, участвуя в священных войнах языков программирования, постоянно забредая в технологические дебри и блуждая по заросшим тропинкам ведения проектов. Идеи, изложенные в «Человеческом факторе», должны придти изнутри, и только тогда можно быть готовым к прочтению этой книги. Иначе, она будет выглядеть не более чем забавной на фоне «глобальных» проблем вывода организации на более высокий статус CMM или оттачивания Методологии.

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

«Peopleware» совершенно неоходима к прочтению как руководителям, так и продвинутым разработчикам, тем кто воспринимает себя мыслящими существами, участвующими в процессе творчества. И совсем необязательно, чтобы этот процесс был связан с построением программных систем.

Проходя мимо рабочих мест коллег невольно обращаешь внимание, что вместо блеклого интерфейса IDE, в которой, собственно, полагается находиться программисту большую часть рабочего дня, видишь на экране яркий дизайн какого-нибудь новостного сайта.

Вообще это нормально — человек должен иногда переключаться. Только вот интересно — насколько он часто это делает? И добыв с полки справочник по математике Т.Корна, взялся решить следующую абстрактную задачу:

Вступление

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

Допустим, в вашей компании работает 100 человек, средняя зарплата 50000р. Таким образом, на зарплату сотрудников вы тратите 5 млн. руб. в месяц (в этом расчете налоги не важны).

Вы экономите на всем, поэтому в вашем офисе на одного сотрудника приходится 3м². За аренду вы платите 700 руб./м², или 210 тыс. рублей в месяц.

А теперь, давайте увеличим площадь офиса, и даже не до 6м² на человека, предписанных санитарными нормами, а до «роскошных» 8м². Затраты на аренду возрастут на 350 тыс. или на 7% от затрат на зарплату.

Знакомо ли вам такое состояние, когда вы настолько увлечены идеей, что полностью погружаетесь в процесс ее реализации, забывая о времени и окружающем мире? А завершив, испытываете радость и даже счастье? Значит, у вас есть опыт потоковых состояний – особых ресурсных состояний сознания, когда все внимание сфокусировано на цели, и в результате замечательные идеи рождаются сами собой, и время концентрируется, вмещая гораздо больше, чем в обычном состоянии.
Тема эффективности потоковых состояний для работы и творчества уже несколько раз поднималась на Хабре, и в этой статье мы хотим обсудить практическую часть – что необходимо для того, чтобы вызывать это состояние «на заказ»?

Принято считать, что для того, чтобы максимально продуктивно решать сложные творческие задачи, требующие сосредоточенности и погружения в «поток», лучше всего подходит тихое, изолированное место. В статье «Всегда ли шум мешает? Исследование воздействия окружающего шума на творческое мышление» (PDF), опубликованной в журнале Journal of Consumer Research, приведены результаты экспериментов, опровергающие это утверждение.

Учёные провели ряд тестов на решение творческих задач, разделив участников на несколько групп, каждая из которых выполняла задания в разных акустических условиях — с низким (50 дБ), средним (70 дБ) и высоким (85 дБ) уровнями шума. В качестве источников шума использовалась смесь аудиозаписей окружающего шума в кафе, дорожного движения и отдалённой стройки. 50 дБ соответствует негромкому разговору или тихой улице, 70 — громким разговорам на близком расстоянии, оживлённой улице, 85 — очень шумной многополосной магистрали, громким крикам. Выяснилось, что качество решения задач в условиях умеренного шума заметно выше, чем в тихих или слишком громких условиях. С громким шумом всё понятно — 85 децибел совершенно не дают сосредоточиться и вызывают слишком большой дискомфорт — участники стремились закончить задание как можно быстрее, чтобы прекратить «пытку» и не особо заботились о качестве решений. Но почему группы, работавшие в относительной тишине показали плохой результат?

Друзья!

11-12 апреля 2013 года проходит одно из самых значимых событий в мире разработки ПО — юбилейная международная конференция Software People. В этом году, конференция проходит в пятый раз, собирая под одной крышей высококлассных специалистов в области разработки ПО.

Продуктивность у одного и того же человека может отличаться в зависимости от времени суток, настроения, коллектива, фазы луны, а иногда и от политической ситуации в Гондурасе. Понятно, что на некоторые факторы вы не в силах повлиять, но сделать жизнь программиста проще, а как следствие — продуктивнее, вам вполне по силам. Итак, что же для этого нужно?

Не устанавливайте рамки

Вроде бы эта тема многократно обсуждалась, но, тем не менее, многие компании заставляют приходить программистов в 9 утра, забывая, что работа разработчика – это творческий процесс (спросите своих сотрудников, как часто решение насущной проблемы приходит во время прогулки, в метро, во время секса), который трудно сочетается со стандартным офисным расписанием. А если еще учесть, что большинство проектов идут из обеих Америк (смещение времени до -8:00), то обязательный приход в 9:00 тем более выглядит странным решением.

Я в тестировании 12 лет, работал в Naumen и Яндексе. Сейчас руковожу отделом тестирования из 150 человек в Контуре и продолжаю работать тестировщиком в одной из команд.

После полугодовых performance review менеджеры из разных команд рассказали, какие цели поставили своим тестировщикам. У каждого пятого была такая: «Научиться оценивать сроки на тестирование задач». Часто такой «оценки сроков» хотят не только от тестировщиков, но и от разработчиков.

Оценка сроков в 95 % случаев. Спасибо, xkcd.

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

Сейчас объясню, как это работает.