The Deadline
Tom DeMarco
Найдите правильных людей. Потом, что бы вы ни делали, какие бы ошибки ни допускали, люди вытащат вас из любой передряги. В этом и заключается работа руководителя.
Выбирать нужно тех, кто принесет нашей стороне экономическую выгоду и одновременно нанесет урон сопернику.
— Если меня берут на работу и сразу же говорят, что я отстаю от графика, это означает только одно: план был нереальным с самого начала.
Безопасность и перемены
- Если человек не чувствует, что находится в безопасности, он будет противиться переменам.
- Перемены необходимы руководителю для успешной работы (наверняка они необходимы и в любой другой деятельности)
- Неуверенность заставляет человека избегать риска.
- Избегая риска, человек упускает все новые возможности и выгоды, которые могли бы принести ему перемены.
- Человека легко запугать прямыми угрозами, но также можно просто дать ему понять, что при случае с ним могут обойтись грубо и жестоко. Эффект будет таким же.
Отрицательная мотивация
- Угрозы — самый неподходящий вид мотивации, если вас волнует производительность сотрудников.
- Чем бы вы ни угрожали, задача все равно не будет выполнена, если с самого начала вы отвели на ее выполнение слишком мало времени.
- Более того, если люди не справятся, вам придется выполнить свои обещания.
— Да. Настоящий руководитель чувствует ситуацию нутром, управляет людьми исключительно сердцем и может вдохнуть живую душу в проект, команду или всю организацию. — Чувствовать нутром… — …все, что касается решений о работе с людьми. Вы читаете чье-то резюме, и на бумаге этот человек подходит просто идеально. Но что-то подсказывает: нужно продолжать поиски. Это «что-то» и есть нутро. И вот вы встречаете другого человека, и этот тихий голос внутри говорит тебе: «Вот он!» или «Вот она!» В этом случае надо тут же нанять человека, ввести его в курс дела и оставить в покое. Так поступают хорошие руководители, которые правильный выбор делают нутром, а не головой. А головой менеджер должен усвоить одно-единственное правило: всегда доверять тому, что подсказывает внутренний голос. — Ага, — задумчиво проговорил мистер Томпкинс. — Ну, а как же сердце? — Люди всегда идут за сердцем, а не за головой. Они никогда не будут с вами просто потому, что вы умнее, или потому, что вы всегда принимаете правильные решения. Они идут за вами, потому что любят вас. Понимаю, звучит это немного странно, но ведь это правда. Все мои бывшие руководители были сердечными людьми. Сердце большое, как дом, — вот суть любого лидера. Конечно, есть менеджеры, которые руководят головой, а не сердцем, но за ними никто никогда не пойдет.
Части тела, необходимые для управления проектами
- Для руководства нужны сердце, нутро, душа и нюх.
- Так что:
- руководить надо сердцем;
- чувствовать нутром;
- вкладывать в команду и проект душу;
- иметь нюх на всякую ерунду и бессмыслицу.
Собеседование и прием на работу.
- Чтобы нанять человека на работу, менеджеру необходимы все его способности: сердце, душа, нюх и способность чувствовать нутром (по большей части последнее).
- Не пытайтесь нанимать людей в одиночку — гораздо лучше задействовать в этом процессе интуицию двух менеджеров
- Попросите новых членов команды взяться в проекте за ту работу, которую им уже случалось успешно выполнять в прошлом, а прочие амбиции и рост отложить до следующего проекта.
- Попросите наводку — тот человек, которого вы выбрали себе в команду, наверняка может посоветовать, кого вам еще следует нанять.
- Больше слушайте, меньше говорите.
я бы всецело сосредоточился на том, чтобы не тратить время зря. Достаточно предположить некий фиксированный уровень производительности труда за час эффективной работы, и тогда вам останется только уменьшать количество неэффективных часов.
Пустые траты и риски всегда ходят вместе, как мне кажется. Пустая трата усилий и времени, которые отбрасывают проект назад, — все это результат материализации риска. А значит, самое главное, что я стал бы делать на вашем месте, — управлял бы рисками. Я бы работал с каждым проектом, просто управляя рисками, которые могут в нем возникнуть. Разработка программного обеспечения — вообще очень рискованный бизнес, и подчас все управление процессом сводится к управлению рисками.
Обычно все начинается с неких признаков того, что риск начинает превращаться в проблему. Вам всегда нужно знать, на какой показатель риска ориентироваться, и не спускать с него глаз.
Повышение производительности
- Не существует никаких краткосрочных мер, которые позволили бы быстро повысить производительность роботы.
- Повышение производительности — результат долгосрочных усилий.
- Любые средства для повышения производительности, которые обещают немедленный результат, на самом деле не что иное, как «птичье молоко»
- Чтобы управлять проектом, достаточно управлять его рисками.
- Создайте список рисков для каждого проекта.
- Отслеживайте те риски, которые являются причиной провала проекта, а не только конечные риски.
- Оцените вероятность возникновения и стоимость каждого риска.
- Для каждого риска определите показатель — симптом, по которому можно определить, что риск превращается в проблему.
- Назначьте специального человека для управления рисками, и пусть он не поддерживает девиз «Мы можем все!», который культивирует начальство.
- Создайте доступные (возможно, анонимные) каналы для сообщения плохих новостей руководству.
Уважение к своей команде — очень хорошая черта в руководителе
Я вообще считаю, что разваливать, делить сложившиеся команды ни в коем случае нельзя. А в некоторых компаниях на этот счет есть формальные правила: как только проект заканчивается, вся команда расформировывается. Идиотизм какой-то! По-моему, появление слаженной, сработавшейся команды в любом проекте можно считать успехом! И об успехе проекта нужно судить точно так же: не просто оценивать качество программного продукта, а учитывать, появилась ли в результате работы сплоченная команда разработчиков, которая готова немедленно продолжать совместную работу и приступить к
— Самое важное, чему надо постоянно учиться, — это умение сокращать потери. Когда вы заняты чем-то полезным, всегда есть риск, что все ваши усилия пойдут прахом. Особенно это заметно в программировании.
— Если вы судите о ходе проекта, исходя из того, что он будет успешным, вы рисуете себе заведомо ложную картину. Совершенно необходимо все время стараться уменьшать потери. Успех зависит от того, насколько быстро вы сумеете отказаться от работы, ведущей к провалу проекта. Это самый ценный и самый сложный урок, который я вынес из всего своего опыта.
Играй в защите
- Сокращайте потери.
- Успех проекта можно скорее обеспечить сокращением ненужных усилий, чем стремлением к новым победам.
- Чем раньше вы прекратите ненужную работу, тем лучше для всего проекта.
- Не пытайтесь создавать новые команды без необходимости; поищите в коллективе уже сложившиеся и сработавшиеся команды.
- Оставляйте команды работать вместе и после окончания проекта (если они сами того хотят), чтобы у пришедших вам на смену руководителей было меньше проблем с плохо срабатывающимися командами.
- Считайте, что команда, которая хочет продолжать работать вместе и дальше, — это одна из основных целей любого проекта
- День, который мы теряем в начале проекта, значит так же много, как и день, потерянный в конце.
- Есть тысяча и один способ потратить день зря и ни одного, чтобы вернуть этот день обратно.
Как руководитель, вы просто обязаны это знать. Поиски компромисса между количеством людей в команде и скоростью работы — это то, с чем менеджеры сталкиваются чуть ли не каждый день. И вы тоже постоянно с этим сталкиваетесь.
Общая производительность зависит от четырех вещей: от размера команды; от того, сколько в ней новичков, которые еще не вошли в курс дел; от «поправки на рост» и от «стоимости интеграции».
Моделирование процесса разработки
- Моделируйте свои предположения и догадки о том, как пойдет процесс работы.
- Обсуждайте эти модели вместе с партнером, чтобы лучше понимать процесс работы и вносить необходимые исправления.
- Предсказывайте результаты работы с помощью модели.
- Сравнивайте результаты, полученные а процессе моделирования, с реальными.
он уже много лет назад выучил одно полезное правило: уважать любого, даже самого вредного из своих подчиненных.
Политика — это наука. Аристотель включил ее в число пяти благородных наук, пяти ветвей философии. Помните? Метафизика, логика, этика, эстетика и политика.
Извращенная политика
- В любой момент нужно быть готовым отказаться от работы и попросить расчет…
- …однако это не означает, что тем самым вы сумеете избежать последствий извращенной политики.
- Извращенная политика достанет вас везде, даже в самой здоровой и чистой организации.
- Главный признак извращенной политики: во главу угла ставятся личные цели и влияние, а не общие интересы компании.
- Это может произойти даже тогда, когда личные цели напрямую противоречат целям организации.
- Один из побочных эффектов извращенной политики: иметь хорошо укомплектованную команду становится небезопасно.
Мистер Томпкинс остановился и перечитал написанное. Последний пункт расстраивал его больше всего. Чем больше они работали с моделями доктора Джамида, тем сильнее убеждались, что маленькие команды могут творить чудеса, в то время как большие за то же самое время едва ли успевали как следует сработаться и набрать темп. Но в обстановке извращенной политики маленькие команды становились несбыточной мечтой. Более того, в такой обстановке руководителю становится небезопасно делать проект силами маленькой команды. Если что-то пойдет не так, обязательно найдутся люди, которые в один голос заявят, что виной неудачи было ваше нежелание добавить в команду десяток-другой программистов. И в такой обстановке рядовой руководитель, скорее всего, согласится набрать в свою команду лишних людей, даже если в глубине души он уверен, что надо делать с точностью до наоборот.
Сбор метрических данных
- Определяйте размер каждого проекта.
- Не усердствуйте поначалу с выбором единицы измерения — если впоследствии вам предстоит работать с реальными данными, для начала сойдут и абстрактные единицы.
- Стройте сложные метрики на основе простых (тех, которые легко подсчитать в любом программном продукте).
- Собирайте архивные данные, чтобы считать производительность труда по уже законченным проектам.
- Работайте над формулами вычисления сложных синтетических метрик до тех пор, пока полученные результаты не будут наиболее точно отражать отношение абстрактных единиц к указанному в архивных данных объему работ.
- Проведите через всю архивную базу данных линию тренда, которая будет показывать ожидаемый объем работ в виде отношения значений сложных синтетических метрик.
- Теперь для каждого нового проекта достаточно будет высчитать значение синтетической метрики и использовать ее при определении ожидаемого объема работ.
- Не забывайте об «уровне помех» на линии производительности и используйте его, как индикатор при определении допустимых отклонений от общей траектории.
Руководства пользователя и есть спецификация требований
Процесс разработки и его улучшение
- Хороший процесс разработки и его постоянное улучшение — весьма достойные цели.
- Но существуют еще и рабочие цели и задачи: хороший работник сконцентрирует внимание как раз на них, даже если вы его об этом не просили.
- Формальные программы, направленные на улучшение существующего процессе разработки, будут дорого стоить команде — и во временном, и в денежном отношении. Даже отдельные усилия по улучшению процесса могут отбросить команду далеко назад. Что касается возможного повышения производительности, то даже если это и произойдет, то едва ли выгоды от этого повышения покроют затраты.
- Можно надеяться получить положительный результат от одного какого-нибудь хорошо взвешенного и тщательно выбранного усовершенствования в методике работы. В этом случае оно может покрыть деньги и время, потребовавшиеся на его внедрение.
- Попытка внедрить более одного усовершенствования методологии — гиблое дело. Программы, направленные на улучшение многих приемов и навыков (например, переход на следующий уровень СММ), скорее всего приведут к тому, что сроки только увеличатся.
- Опасность стандартизированного процесса разработки состоит в том, что за рутинными операциями люди могут не заметить возможность сэкономить время и усилия по разработке проекта.
- Что касается чрезмерно больших команд, то там стандартизированный процесс будет неукоснительно соблюдаться до тех пор, пока он позволяет всем чувствовать себя при деле (не важно, с пользой для проекта или нет).
Улучшение процесса разработки положительно сказывается на производительности, но только по прошествии какого-то времени. А поначалу это будет довольно дорого стоить команде.
Количество времени, которое нужно нам для отладки и исправлений, прямо пропорционально количеству ошибок
Делать работу по-другому
- Есть только один способ сократить время на разработку, когда его и без того мало — уменьшить сроки отладки программы.
- Проекты с высокой производительностью требуют гораздо меньше времени на отладку и исправление ошибок.
- Проекты с высокой производительностью требуют гораздо больше времени на проектирование.
- Нельзя заставить людей делать что-то по-другому, если ты о них не заботишься, если ты ими не интересуешься. Чтобы они изменились, ты должен понимать (и ценить) их самих, что они делают и к чему стремятся.
Давить незачем — люди все равно работают на пределе своих возможностей.
Что дает давление сверху
- Люди не начнут быстрее соображать, если руководство будет давить на них.
- Чем больше сверхурочной работы, тем ниже производительность.
- Немного давления и сверхурочной работы могут помочь сконцентрироваться на проблеме, понять и почувствовать ее важность, но длительное давление всегда плохо.
- Возможно, руководство так любит применять давление, потому что просто не знает, как еще можно повлиять на ситуацию, или же потому, что альтернативные решения кажутся им слишком сложными.
- Ужасная догадка: давление и сверхурочная работа призваны решить только одну проблему — сохранить хорошую мину при плохой игре.
Мы берем на себя много, потому что мало чего боимся
Когда работы становится все больше и больше, а сроки поджимают, команда может стать единым целым и сообща стараться решить поставленную задачу.
Сердитый начальник
- Злость и неуважение заразительны. Когда высшее руководство демонстрирует злость и неуважение к подчиненным, руководители среднего звена начинают копировать их поведение. Точно так же дети, которых наказывали в детстве, часто впоследствии становятся жестокими родителями.
- Неуважение и злоба, по мнению некоторых начальников, должны заставить подчиненных лучше работать. Это типичная политика «кнута и пряника». Но разве когда-нибудь неуважение со стороны начальства приводило к тому, что люди начинали лучше работать?
- Если начальник демонстрирует неуважение к подчиненным, это признак того, что он не может больше занимать свою должность (а вовсе не признак того, что у него плохие подчиненные).
Спецификация — это описание того, как система — некий набор запланированных реакций — отвечает на события, которые происходят непосредственно за ее пределами. Любая спецификация делится на две части: первая описывает зависимость между определенными событиями и реакцией системы. Вторая описывает входящие и исходящие данные, благодаря которым события и реакция системы становятся единым целым. Какой бы сложной ни была система, вторую часть всегда достаточно просто описать: все эти входящие и исходящие данные — просто список неких данных и управляющих элементов. Всех их можно поименовать, пронумеровать и перечислить. К тому же их можно измерять (например, по количеству информационных элементов в потоке).
Туманные спецификации
- Неясность спецификации говорит о том, что между участниками проекта есть неразрешенные конфликты.
- Спецификация, в которой нет списка типов входящей и исходящей информации, не должна даже приниматься к рассмотрению. Это значит, что она попросту ничего не специфицирует.
- Никто никогда не скажет вам, что спецификация плоха. Люди скорее будут обвинять себя в неспособности понять написанное, чем ругать авторов спецификации.
Во-первых, нужно выработать привычку проявлять уважение и понимание к любому конфликту и не давать ему уйти вглубь организации и внутрикорпоративных отношений. Во-вторых, нужно разработать способы подключения к конфликту посредников.
Конфликт
- Проект, в котором участвуют несколько сторон, обязательно столкнется с конфликтом интересов.
- Процесс создания и распространения программных систем — прямо-таки рассадник всевозможных конфликтов.
- В большинстве компаний, где создается программное обеспечение, никто специально не занимается вопросом решения конфликтов
- Конфликт заслуживает понимания и уважительного отношения. Конфликт не имеет ничего общего с непрофессиональным поведением
- Донесите до каждого, что постараетесь учитывать интересы всех участников, и проследите, чтобы так оно и было.
- Тяжело договариваться. Гораздо легче выступать посредником
- Объявите заранее, что если интересы конфликтующих сторон полностью или частично противоположны, то поиск решения будет переложен на посредника.
- Не забывайте: мы находимся по одну сторону баррикад. По другую сторону находится сама проблема.
Кто такой катализатор проекта
- Существуют люди-катализаторы. Они помогают создать здоровую команду, отношения, боевой дух. Даже если бы они больше ничего не делали (а как правило, они делают куда как много), их роль в проекте остается одной из наиболее важных.
- Посредничество — еще одна сфера, в которой люди-катализаторы просто незаменимы. Впрочем, посредничеству можно научиться, это не очень сложно.
- Первым шагом к посредничеству должна быть маленькая церемония. Например, можно произнести фразу: «Вы позволите мне попробовать помочь вам решить этот спор?»
Человеку свойственно ошибаться
Нам кажется, что самое страшное — не знать чего-то. На самом деле гораздо хуже быть уверенным, что знаешь, когда на самом деле это не так.
Эти команды слишком большие. Когда приходит время заниматься дизайном, команда оказываеся слишком большой. Продумывать архитектуру системы хорошо вдвоем, втроем. Ну, в крайнем случае, можно поручить это четверым или пятерым. Пять человек могут собраться вокруг доски для записей и вместе придумать хорошее решение. Но двадцать человек вокруг доски для записей уже не соберешь.
Определение архитектуры приложения — это, по сути, деление целого на части, очень важный этап в разработке программы. Как только вы его прошли, части можно раздавать для выполнения различным людям или командам. Пока вы этого не сделали, у вас нет никаких частей и раздавать вам нечего. Следовательно, вся команда должна работать вместе.
взаимодействия между людьми аналогичны взаимодействиям между частями проекта
- Если в самом начале проект делает большая команда, это снижает эффективность самой ответственной части работы — определения архитектуры системы (потому что всем разработчиком надо скорее дать какую-то работу).
- Если работу раздать людям и командам еще до того, как завершится стадия дизайна продукта, не получится создать простые и эффективные модели взаимодействия между людьми и рабочими группами.
- Это приведет к потере независимости, увеличению числа собраний и совещаний, общему недовольству.
- В идеале было бы хорошо сначала набрать маленькую команду, которая создала бы продуманную архитектуру системы, а уже потом, на последнюю, шестую часть времени разработки в эту команду можно было бы добавить новый персонал (который работал бы непосредственно над кодированием).
- Ужасное предположение: кажется, те команды, перед которыми не ставят жестких сроков, заканчивают работу быстрее!
Когда из политических соображений делают вид, что мертвый проект еще жив, это называется «делать зомби». Я думаю, что около десяти процентов всех проектов по производству программных приложений во всем мире — зомби вроде вашего.
Он злился, потому что был напуган. Страх в нашем обществе почему-то нельзя демонстрировать. А вот злость можно. Но когда ты испытываешь сильную эмоциональную перегрузку, тебе просто необходимо выплеснуть свои чувства. Именно поэтому люди, испытывающие страх, чаще всего демонстрируют на людях злость и презрительное отношение к другим. Злость становится суррогатным воплощением страха.
Проблемы социологии
- Собрания должны быть небольшими. Для этого нужно сделать так, чтобы люди не боялись пропускать ненужные им собрания. Самый простой способ — заранее опубликовать повестку дня, а потом всегда строго ее придерживаться.
- Каждому проекту нужна какая-то церемония или ритуал.
- С помощью церемоний можно концентрировать внимание собравшихся на основных целях и задачах совещания: сократить состав рабочей группы, повысить качество программного кода и т. п.
- Защищайте людей от оскорблений и ругани Начальства.
- Запомните: в работе страх = гнев. Те руководители, которые любят кричать на своих подчиненных и всячески унижают и оскорбляют их, на самом деле просто чего-то очень боятся.
- Наблюдение: если бы для всех проявление грубости и злости к подчиненным всегда значило бы, что начальник просто боится, то никто из начальников не стал бы так себя вести просто из страха, что его страх станет заметен! (Это, конечно, не решает проблем такого руководителя, но, по крайней мере, оберегает его подчиненных.)
Если ты прав, то получается, что проверка кода, на которую так полагается весь остальной мир программистов, — это всего лишь попытка найти и исправить ошибки в проектировании системы. А когда архитектура продумана и проверена достаточно хорошо, причем еще до того, как программисты начнут писать код, то проверять код просто незачем.
О патологической политике (еще раз)
- Эту патологию невозможно вылечить снизу.
- Не стоит терять время или подвергать себя опасности, чтобы проверить предыдущий постулат на собственном опыте.
- Иногда единственным выходом из ситуации становится выжидание. Попробуйте подождать, пока проблема не разрешится сама по себе или пока вы не найдете способ уйти от нее в сторону.
- Чудеса, конечно, случаются, но лучше все же на них не рассчитывать.
Злоба и скупость
- Злоба и скупость — вот формула, которую начинают применять в плохих компаниях те, кто несет ответственность за неудачи в бизнесе.
- Злоба и скупость прямо противоположны истинным целям любой хорошей компании — быть щедрыми и заботливыми по отношении к своим сотрудникам.
- Когда вы подмечаете в компании проявления злобы и скупости, знайте, их настоящая причина — страх и боязнь провала.
Основы здравого смысла
- У проекта должно быть два срока сдачи — запланированный и желаемый.
- Эти сроки должны быть разными.