Читаю книгу:
ITпроекты: фронтовые очерки
Джо Мараско
Хорошая книга.
Вместо отзыва или аннотации дальше пойдёт трейлер к книге, нарезка интересных фрагментов.
* * *
Хороший управляющий может повысить эффективность работы отличной команды, но, как мне однажды сказал знающий завсегдатай ипподрома, «я еще не видел жокея, который тащил бы свою лошадь через финишную прямую».
(Начальник не создаёт продукт; он либо помогает, либо мешает)
* * *
Весьма опасно, когда старший по должности выдвигает (по своему неведению) неразумные требования, а управляющий программным проектом уступает ему (со слишком большой готовностью), тогда как не должен был этого делать.
(Смотри историю со шведской Вазой)
* * *
Вот неплохой ориентир – остановиться надо в том случае, если на этапах наблюдения и слушания получено очень мало существенной новой информации.
(Нет опыта, нет действий)
* * *
Но в конечном итоге результат никогда не бывает точнее входных данных.
* * *
И по иронии судьбы мы не тратили много усилий на код, проверяющий правильность входных данных. Ведь компьютер – это инструмент для профессионалов, т. е. инженеров. Представить себе, что компьютером станут пользоваться «обычные граждане», а потому потребуется проверять вводимые данные, было так же сложно, как вообразить прогулку человека по лунной поверхности.
(Именно поэтому тестировать должен хотя бы не тот, кто разрабывал)
* * *
Иногда в финансовых отчетах вы обнаруживаете, что итоги лишь чуть-чуть расходятся, и соблазнительно объяснить это «ошибками округления». Но очень часто оказывается, что совершены две существенные ошибки разного знака, почти погасившие одна другую. Когда боги вычислений милостивы к нам, они подкидывают такие ключи. Не поленитесь воспользоваться ими и всегда помните золотое правило Ричарда Хемминга: «Цель вычислений – понимание, а не
числа».
(Финансы редко делят и умножают, поэтому ошибки округления в финансовых отчётах возможны только в определённых местах, например: расчёте налогов или амортизации)
* * *
Создание большой программной системы очень напоминает подъем на большую гору. В обоих случаях цель вполне ясна и требует координированных усилий команды высококвалифицированных специалистов, находящихся в обстоятельствах, которые они могут предвидеть и к которым могут приготовиться, но которые им не подвластны.
(Интересная и полезная аналогия)
* * *
У старых моряков есть поговорка: «отличный моряк благодаря своему отличному здравому смыслу избегает таких ситуаций, в которых ему понадобится его отличное мастерство»
(Самый лучший код – это код, который не написан)
* * *
Каждый должен быть в связке, состоящей хотя бы из двух человек.
(Жаль, что у меня нет людей в связке)
* * *
Всегда стремитесь сформировать как можно меньше групп как можно меньшей численности каждая. Четыре группы по три или четыре участника могут составить очень продуктивную команду.
(Двенадцать человек – идеальная команда)
* * *
Для программного проекта продолжительностью от 18 до 24 месяцев правильным кажется выбор контрольных точек с промежутком в 3–4 месяца.
* * *
Однако нельзя позволить себе впасть в парализованное состояние и продолжать откладывать принятие решения – синдром «паралича при анализе». Необходимо потратить какое-то время и рассмотреть варианты, собрать данные, а потом принять решение. Приняв решение, надо выполнять его и не терзаться сомнениями.
(Смотри парадокс с Буридановым Ослом)
* * *
Я считаю, что морально равноценным подъему на вершину и благополучному спуску обратно является выпуск программного продукта, который вы в состоянии сопровождать и поддерживать. Это означает, что сам программный продукт должен устойчиво работать, документация должна
быть полной и понятной, а бремя поддержки не должно отнимать все силы организации. Поэтому планирование программного проекта должно охватывать всю работу, а не только установку флага на вершине.
(Продуктивный старт важнее внутренних майлстоунов)
* * *
Я помню, что в молодости был подвержен известной болезни считать всех своих начальников идиотами.
(В детстве все взрослые кажутся дураками)
* * *
Кроме того, надо держать команду в форме, для чего поставить перед ней достойную цель – справиться с решением трудных задач.
(Не любая цель может заинтересовать охотника)
* * *
Иногда для этого приходится выяснить, каковы действительные проблемы клиента – в противоположность его мнению об этом.
(Клиент не может сформулировать свои желания)
* * *
Лучше попробуйте понять, в каком качестве – лидера или менеджера – ваш основной кандидат проявит максимальную эффективность, а потом попытайтесь найти того, кто сможет дополнить его.
(Никто не идеален, каждый человек должен быть в связке)
* * *
Простое наблюдение показывает, что если не обращать внимания на мелкие проблемы, то они вырастают до больших. Это справедливо, например, для чувства неудовлетворенности, испытываемого сотрудниками: если ничего с ним не делать, оно развивается и усугубляется.
(Усугубляется)
* * *
Не слушать людей – это большой грех. Если вы считаете, что слишком заняты для этого, значит, вы неверно расставили приоритеты. Необязательно выслушивать всех и каждого, необязательно и прислушиваться ко всем одинаково, но слушать необходимо.
(Слушать, а не слышать)
* * *
Отделяйте факты от мнений. Кроме того, отделяйте факты от их последствий и смысла. Часто обо всем этом говорят одновременно или путают друг с другом.
(Не путайте тёплое с мягким)
* * *
Никогда не объясняйте злонамеренностью то, что можно объяснить некомпетентностью.
(Как правило люди - дураки, а не злодеи)
* * *
Команды прощают своим менеджерам множество грехов, но некомпетентность, лень, отсутствие награды за старание и отсутствие чувства юмора не входят в это число.
(К менеджеру – особые требования)
* * *
Никогда не принимайте человека, с которым вы не чувствуете себя комфортно, хотя иногда можно и рискнуть. Однако если риск кажется вам достаточно большим и вызывает тревогу, доверьтесь чувствам и откажите этому человеку. Ошибки в подборе сотрудников оказываются одними из самых дорогостоящих.
(Отсутствие комфорта в том числе мешает “войти в поток”)
* * *
При этом обычно, как и в «подковках», вмешиваются три важных фактора:
- Цель оказывается не там, где ты рассчитывал
- Во время работы люди совершают ошибки
- Вдобавок ко всему цель движется
(Законы Мёрфи в действии)
* * *
Мы оба знаем, что анархия тоже неэффективна. Она просто влечет бессмысленное реагирование на малозначительные события. По-моему, у вас, физиков, это называется броуновским движением. Бурная активность и слабый прогресс.
(Бурление говн – тоже)
* * *
Мораль сей истории: определите приоритет своих рисков и начните с самого опасного. Если в результате не останется времени на решение «простых задач», значит, вы в любом случае были обречены на провал.
(Интересно, а для меня архитектурная последовательность обычно важнее. Впрочем это особенности бизнес-ориентированного ПО – например: в игродельном ПО есть приоритеты важнее архитектуры)
* * *
Это все равно, что путать карту с местностью. Или объяснять провал плохими инструментами. Если действующий план ведет к катастрофе, МЕНЯЙТЕ ЭТОТ ПЛАН!!!
(Да!)
* * *
Подлинно опасными оказываются картинки «уровня менеджмента», какие часто встречаются в презентациях PowerPoint. Эти картинки претендуют на то, чтобы сообщить нам что-то, но на практике обычно оказываются чрезвычайно неясными и расплывчатыми. Они не сильно превосходят наборы графических примитивов. Каждый может понимать их, как ему угодно.
(PowerPoint – важный инструмент для ИБД и зомбирования)
* * *
Если же пользователь задумал другое животное, он отвечает «нет». Удрученная программа сообщает: «Увы, я не угадала ваше животное. Назовите мне его и введите вопрос, на который нужно ответить „да“ для вашего животного и „нет“ для гончей».
(Вот оказывается из чего вырос Акинатор)
* * *
Лучший способ освоиться с новым языком программирования состоит в том, чтобы запрограммировать стандартную задачу, которая вам уже знакома. Это позволит вам изучить язык и узнать, «как это сделать» для известного набора практических вопросов. Моя стандартная задача служила мне долгие годы, и я считаю, что она заставляет решать минимальный, но полезный набор базовых проблем.
(Акинатор)
* * *
Можно также сказать, что для любой цивилизации любые попытки совершать прогресс представляют собой попытки бросить вызов энтропии. Можно сказать то же самое и иначе: превращение хаоса в порядок требует работы, и как только такая работа прекращается, система будет самопроизвольно двигаться в направлении беспорядка.
(Занятно, что это откликается в наименовании моего блога)
* * *
Однако в большинстве организаций желание устранить политику не обязательно приводит к ее реальному устранению. Политика – это неотъемлемая часть окружающего нас реального мира, и с ней приходится иметь дело.
(Смотри термин “Хорошая политика”)
* * *
Попытайтесь убедить группу, что кто-нибудь должен быть назначен главным, поскольку свободная конфедерация обречена на провал.
(У семи нянек дитё без глаза)
* * *
Первый печально известный капкан такого рода – это так называемые религиозные войны. Во всякой организации есть гуру, которые свято верят, что они (и только они) знают магическую формулу «правильного» процесса. И почти наверняка в этой же организации найдутся несколько членов оппозиции, так же свято убежденных в своей правоте. Вне зависимости от того, кто оказывается прав, эти крестовые походы абсолютно непродуктивны и зачастую вращаются вокруг смутных и малозначительных деталей.
(Холиварить, холиварить, холиварить!)
* * *
Наконец, не затягивайте установление процесса. Лучшее – враг хорошего. Процедуру надо разрабатывать итеративно – точно так же, как программное обеспечение. Приступайте к итерации номер 1 как можно скорее. Учитесь. Изменяйте. Улучшайте. Повторяйте, пока не закончите.
(Итераций – всегда минимум две)
* * *
Возвращаясь к аналогии с фабрикой, нужен некто, кто будет наблюдать за конвейерной линией и проверять качество выходящих с нее продуктов. Этот некто должен бдеть неусыпно, иначе очень легко получить прекрасно автоматизированный процесс, дающий результаты отвратительного качества.
(Главное чтоб было кому назвать говно говном)
* * *
Как и во всех остальных аспектах разработки ПО, при работе над механизмом сборки есть лишь несколько способов сделать все правильно и безграничное число способов сделать все не так.
(Все счастливые семьи похожи друг на друга, каждая несчастливая семья несчастлива по-своему)
* * *
Риск, по-видимому, является важнейшим параметром, который надо учитывать при финансировании и планировании проекта. Вот почему простая модель, которую я описал в этой главе, связывает четыре традиционных параметра проекта – охват, качество, скорость, экономичность – и добавляет риск в качестве пятой переменной.
(Риск – не благородное дело)
* * *
Данная простая модель пирамиды также показывает, какие уступки вам придется сделать, чтобы повысить вероятность успеха. Несмотря на свою абстрактность, эта модель позволяет трезво оценить, готовы ли мы обеспечить ресурсы, необходимые, чтобы поднять вероятность успеха выше минимального порога, приемлемого в нашем бизнесе, исходя из заданных ограничений на охват, качество и время.
(Интересная концепция)
* * *
Вынужден признаться, что мне не удалось понять, как добиться точности в оценке времени. Я лишь обнаружил, что молодые и менее опытные разработчики склонны к излишнему оптимизму.
(Другая особенность неверной оценки – как правило оценивается операция, не имеющая опытного подтверждения)
* * *
Хороший менеджер должен быть очень терпелив и работать над тем, чтобы установить атмосферу доверия в отношении оценок. Никого нельзя строго наказывать за то, что он не смог дать объективную оценку и не скрыл это. А вот с безответственностью оценок (определением сроков без достаточных оснований) и перестраховкой надо активно бороться.
(Умножать на два – никогда не вариант)
* * *
Не нужно быть Эйнштейном, чтобы понять почему. По той же логике для снижения ошибки до 1% надо опросить 10 000 человек. Это в 10 раз дороже, чем опросить тысячу. Поэтому, чтобы понизить ошибку с 3% до 1%, надо увеличить издержки в 9 раз.
(Достаточность – важный критерий предварительной оценки, поэтому иногда для грубой оценки можно действовать с точностью до порядка)
* * *
Любопытно также было видеть, что Роско не желает иметь дело с промежутками времени короче недели. «Мы, сынок, не поденщики, – заявил он. – Я плачу своим инженерам понедельно. Потому я не пользуюсь для оценок меньшими интервалами».
(Это значит, что в график работ работ пункты длительностью менее недели должны включаться только оптом)
* * *
Вот тут написано, как ты и этот парень Крухтен заметили, что длительность итерации в неделях примерно равна квадратному корню из длины кода, который нужно написать, если измерять ее в тысячах строк.
(Программа на 1000 строк занимает неделю, 4000 – две недели)
* * *
Длительность одной итерации должна быть равна квадратному корню из общей длительности проекта.
(Годовой проект = 7 итераций)
* * *
В результате возникла позорная игра в «два графика», когда есть «внутренний график» с намеренно сжатыми сроками – чтобы разработчикам не казалось, что у них много времени, – и «внешний график», в котором для страховки сроки внутреннего графика увеличены, – для показа всем остальным.
(Игра становится ещё более позорной, если и внутренний график не соответствует реальным работам)
* * *
Я рекомендую иметь один график и стараться сделать его максимально честным.
(Честность – лучшая политика)
* * *
Мне приходилось встречать разумных во всех других отношениях людей, которые наивно пытались выполнять роль посредников между компетентными и некомпетентными людьми, придавая одинаковую важность идеям тех и других. Это бесполезное занятие, которое раздражает обе стороны и может удручающе подействовать на действительно компетентных людей.
(Метать бисер перед свиньями)
* * *
Часто система ценностей инженеров дает о себе знать любопытным и противоречивым образом. Например, они, как правило, испытывают дискомфорт, общаясь с клиентами, если считают, что не все, что те говорят, – чистая правда. Здесь они руководствуются стандартами, которые иногда оказываются слишком строгими. Но их очень удивляет, когда их собственная честность ставится под сомнение, если они не сумели уложиться в график в какой-то контрольной точке. Для них это всего лишь техническая проблема, а не нарушение обязательств или злоупотребление доверием.
(Занятный парадокс, имеет место быть. Именно из-за него я не люблю озвучивать сроки.)
* * *
Замечательное свойство среды с высоким доверием – ее чрезвычайная эффективность. Если есть доверие, меньше надобности в проверках. В результате меньшая команда может выполнить больше работы. Это все равно, что уменьшить трение в механизме: больше энергии пойдет на совершение работы и меньше – на выработку тепла. Обычно высокого доверия проще достичь в небольших и относительно однородных группах.
(При наличии в команде разработчика с малым доверием я буду тратить время на паранойю независимо от качества его работы)
* * *
Поэтому не удивляйтесь, если в разговоре с инженерами и техническими менеджерами обнаружите, что они сваливают «нейтральную (пограничную) зону» и «плохую» политику в одну кучу, презрительно называя ее «политикой», а категорию «хорошей» политики характеризуют как «лидерство» или «правильное управление».
(Так)
* * *
Существует такая особенно вредная форма политики, как нежелание «подчиниться». В каждом процессе за периодом обсуждения следует принятие решения.
(Это правда, авторитет бывает важнее правильности. И тем не менее, это мнение руководителя, но за собой я такую “вредность” наблюдаю)
* * *
Наконец, существует проблема стиля, часто относимая к политическому поведению обычно негативного характера. Есть люди, любое взаимодействие с которыми превращается в преодоление препятствий: они всегда «напрягают» окружающих.
(Наблюдаю за собой, но как “не руководитель” хочу отметить, что цель делать друг другу приятно – ни в коей мере не является целью проекта)
* * *
Но у меня постоянно вызывает беспокойство (полагаю, что обоснованное) то обстоятельство, что из-за нежелания разработчиков программ участвовать в процессе, рассматриваемом ими как политический, организация терпит значительный ущерб.
(Видимо, это моё самое большое упущение)
* * *
Во-первых, запомни, что имеешь дело с инженерами. Инженеры обычно не любят вести светские беседы: они считают это бесполезной тратой своего времени. А время свое они ценят дорого. Поэтому прежде всего они хотят знать, в чем заключается задача.
(В этом смысле больше всего не люблю начинание диалога с “Как дела?”)
* * *
Иногда он недовольно ворчит в ответ и быстро объясняет, почему твоя задача вовсе не является задачей. Иногда оказывается, что твоя информация была неверна. А иногда, что задача поставлена некорректно. Вполне уместно проявить настойчивость. Если сумеешь более четко описать задачу, то заслужишь некоторое уважение инженера. Не забывай, что инженер старается оценить как тебя самого, так и твою задачу. Он ни секунды не потратит на задачу, которую считает никчемной или нестоящей. Если у вас разногласия, лучше обсудить их, потому что пока он не будет убежден в том, что есть достойная задача, ты ничего от него не получишь.
(Подтверждено практикой неоднократно)
* * *
Инженер желает знать, что должно быть сделано. Он не желает слышать от тебя, как это должно быть сделано. В конце концов, это то, за что ему платят деньги. Если ты бодро подходишь к нему с готовым решением, почти наверняка у вас возникнут разногласия. Есть и другая проблема, которая возникает, если предлагается готовое решение. Часто инженер, исходя из твоего «решения», пытается выяснить ход твоих мыслей и определить, что тебе нужно в действительности.
(Если ты знаешь, как это должно быть сделано – ты нашёл не того человека)
* * *
Инженеры люди занятые. Задач у них всегда больше, чем времени на их решение. Часть этого времени ты у них уже отнял своими шагами с первого по третий. И оно будет потрачено впустую, потому что без шага четвертого все на том и закончится, как только ты выйдешь из комнаты.
Если ты хочешь, чтобы инженер действительно что-то сделал, ты должен сказать об этом ясно и четко. Это надо выразить явно и недвусмысленно. И если он берет на себя обязательство что-то сделать, то, конечно, надо предложить ему установить срок.
(Нет события – нет реакции)
* * *
Следи за тем, чтобы не давать инженерам-программистам слишком много заданий одновременно. Они считают, что лучше всего работают, когда концентрируются на одной задаче, отдаваясь ей полностью. Им известно, что такое многозадачность, но они не считают такой режим оптимальным для работы. И знаешь, – подмигнул он мне, – если они так считают, возможно, так оно и есть.
(Так оно и есть, но очередь работ должна быть проглядываемая)
* * *
Люди, только что сорвавшие срок выпуска продукта, начинают долго объяснять, какие большие усилия они приложили, как будто это снимет с них ответственность. Им кажется, что их старания служат доказательством благородных намерений, а потому их следует простить.
(Смотри некомпетентность vs злонамеренность)
* * *
Моя гипотеза: в большинстве проектов неприятности происходят из-за накопления всех невыполненных обязательств. И это одна из причин, по которым менеджеры проектов обычно не могут понять, чем вызван провал. Не было какой-то одной большой поломки: просто накопилась масса мелочей. Это очень коварно.
(Опоздание на год = 365 опозданий на один день)
* * *
Это называется жертва большого проекта. Во всех крупных проектах люди считают, что кто-то другой опоздает еще больше, чем они сами. Им кажется, что если они слегка задержатся, это будет незаметно на фоне чьей-то крупной задержки.
(Это как прятать мусор под ковёр, надеясь на пожар)
* * *
Во-вторых, стоит подумать о том, чтобы чаще закрывать проекты на ранних стадиях. Я слишком
часто сталкиваюсь с графиками, которые лишь суммируют самые оптимистичные оценки для подзадач. Это не графики работы, а бесплодные мечтания. Такие проекты заранее обречены на провал. Исполнители говорят своим менеджерам то, что тем хотелось бы слышать, а менеджеры слушают, как завороженные. Проходит несколько месяцев или лет, результаты этого фарса обрушиваются вам на голову, и начинается охота на ведьм. ЭТУ ПОРОЧНУЮ ПРАКТИКУ НАДО ПРЕКРАТИТЬ!!!
(Прекратить!)
* * *
В обоих случаях в среднем ряду (В и З) участник команды, получающий адекватную оплату и не находящийся в состоянии потока, становится все менее продуктивным по причине тревоги или скуки.
(Два неприятных состояния. Наблюдаю за собой, что с часто большим скрипом выполняю тривиальные задания)
* * *
Обратите внимание, что из всех восьми неоптимальных ситуаций только одну можно корректировать простым увеличением вознаграждения.
(Не всё упирается в деньги)
* * *
Инженеры-программисты могут извлечь для себя несколько полезных уроков из катастрофы «Вазы».
(История на века)
* * *
В третьем десятилетии XX века Элтон Майо открыл эффект Готорна. Он продемонстрировал, что при изучении человеческого поведения трудно разделить изучаемое поведение и те изменения, которые неизбежно происходят, когда изучаемой группе известно, что она подвергается изучению. По этой причине сегодняшние медицинские эксперименты проводятся двойным слепым методом: ни пациент, ни врач не знают, кто получает лекарство, а кто плацебо.
(Великое открытие, также как и вообще исследование эффектов плацебо и ноцебо. Смотри также слепое прослушивание у аудиофилов)
* * *
Замкнутая система, предоставленная самой себе, стремится к состоянию максимальной энтропии, и это совершенно верно, но экономические системы, такие как компания, в которой вы работаете, не являются «замкнутыми». Они открыты потокам вещества и энергии. И обычно мы не оставляем свои компании в изоляции. Мы постоянно пополняем их запасы исходных материалов; мы работаем в системе; мы тратим энергию на борьбу с энтропией. Так же, как я стараюсь расчистить свой стол и навести на нем порядок (уменьшить энтропию), я могу вложить свой труд в развитие каналов и механизмов связи своей компании, чтобы уменьшить беспорядок.
(Именно поэтому лично мы можем что-то сделать с этой энтропией)
* * *
Затем, чтобы включить его, надо купить батареи. У каждого устройства должны быть батареи своего типа. Тут же вместе с батареей вы получаете ПО. Подробности технической реализации я здесь опускаю. Можете считать, что вы приобретаете «комплект с батареями». Для маркетинга я выбрал бы название «умная батарейка».
(А это наверное самая сомнительная из идей, высказанных в книге)
* * *
Инструмент не должен определять метод решения. Как тут не вспомнить старую поговорку: когда у вас нет ничего, кроме молотка, все кажется похожим на гвоздь.
(Но инструмент созданный специально для решения задачи должен не дать вам создать новый велосипед, не?)
* * *
Подведем итоги. Чтобы сократить 12-месячный график на два месяца, мы должны поднять численность занятых на 50% и увеличить стоимость продукта на 25%.
(И это если добавлять сотрудников с начала. Вероятно добавление сотрудников на полпути не изменит строк, а добавление в конце увеличит срок до 16 месяцев)
* * *
Так всегда бывает: слабостями и причудами мошенников заполнены страницы газет и эфирное время, а честным людям достается мало славы, даже если они в большинстве.
(Эффект молчаливого большинства)
* * *
Умники, вещающие о качестве, обожают забраться на трибуну и прочесть лекцию о необходимости повышать качество поставляемых нами программных продуктов. Но все несколько сложнее. Качество – весьма субъективная цель.
(Но иметь критерии – важно)
* * *
Какой бы совершенной ни была спецификация требований к программному обеспечению, она не имеет значения, если отсутствует результат, видимый клиенту, – продукт.
(Работающий продукт важнее исчерпывающей документации)
* * *
На смену сильной культуре часто приходит бюрократическая система, призванная контролировать и осуществлять широкий круг стратегий и процедур, которым несвойственны прежние представления о «правильных действиях». Если культура организации слаба, последняя скатывается к дотошному вниманию к мелочам, как будто можно восстановить дух закона за счет роста численности его букв.
(Бюрократия может только снижать КПД, культура и регламенты – вернее ведут к цели)
* * *
Еще одна интересная угроза возникает, когда есть один крупный клиент или партнер с очень сильной культурой. В таком случае скрытые и не очень влияния могут проникнуть в вашу организацию. Например, принятый клиентом или партнером стиль сообщения о результатах может наложиться на некоторые проекты; постепенно это может распространиться среди сотрудников, и все внутренние подразделения начнут докладывать таким же образом.
(А если единственный клиент – одно государственное учреждение, то это реально влияет)
* * *
Помните, что культуры и ценности меняются крайне медленно. Больше шансов, что вы постепенно адаптируетесь к культуре, а не эта культура изменится в направлении ваших вкусов. Поэтому ищите совместимую культуру, если, конечно, вы не любитель плыть против течения.
(Одно из двух)
* * *
Читайте в библиотеках города!