Комментарии 15
НЛО прилетело и опубликовало эту надпись здесь
Уважаемый Дмитрий, в разделе «Что Брукс упустил» Вы выдвигаете идеи об ошибке и возможном решении. Хотел бы обратить Ваше внимание на то, что речь в случае Брукса идет о работе на границе известных вещей и за ней. Фредерик Брукс работал над передовым проектом, применял новые решения, а не воспроизводил старые. Хотя это и выглядит очевидным, но я вижу регулярное повторение ошибки разными людьми на разных уровнях: когда они переходят от работы над стандартными задачами, и берутся за что-то, находящееся на границе их познания или за ней, инструменты продолжают применять те же самые, что применяют к привычным задачам. В том числе, это касается планирования. И ошибка делается даже наедине с собой, не то что перед лицом бизнеса.
Мне довелось видеть успешные примеры: перед началом работы выявляются области незнания, и помимо исследования и экспериментов, они на каждом очередном этапе разработки (неважно о каком продукте речь — программном или нет) переоцениваются заново, а так же оцениваются их стыки с известными частями. Ну а известные планируются стандартно. Этот прием не обещает гарантированный ответ сколько месяцев и долларов понадобится. Тем не менее, он закладывает коррекцию неправильных взглядов — специалисты, работающие над проектом, обязуются сразу и постоянно отслеживать определенные задачи и их структуру, а не просто брать-выполнять-завершать.
Ожидать же от бизнеса понимания в данной ситуации — все равно что ожидать этого же понимания от того, кто будет реализовывать проект. Они все способны совершить одну и ту же ошибку. То есть, тому кто осознает ошибку и пытается ее корректировать, придется отстаивать свою позицию и соответствующие действия. Чтобы это не было досадной необходимостью по факту, нужно осознавать это как обязательные условия изначально.
Еще одно небольшое дополнение. Утверждение «Планируйте выбросить первую версию — вам все равно придется это сделать, потому что она не удовлетворит ожидания пользователей» реализовано в виде приема у некоторых писателей и, особенно, у переводчиков. Специалист начинает работать над текстом, продвигается от начала к концу, и в финале отбрасывает начало (возможно, и середина), и делает его заново. В основе приема лежит простое явление: в начале работы специалист еще не знаком с материалом над которым работает (переводимый текст, создаваемый сюжет). И это относится к типовым задачам в данных отраслях. Если же повысить планку, то многие классические литературные произведения переписывались более одного раза.
Мне довелось видеть успешные примеры: перед началом работы выявляются области незнания, и помимо исследования и экспериментов, они на каждом очередном этапе разработки (неважно о каком продукте речь — программном или нет) переоцениваются заново, а так же оцениваются их стыки с известными частями. Ну а известные планируются стандартно. Этот прием не обещает гарантированный ответ сколько месяцев и долларов понадобится. Тем не менее, он закладывает коррекцию неправильных взглядов — специалисты, работающие над проектом, обязуются сразу и постоянно отслеживать определенные задачи и их структуру, а не просто брать-выполнять-завершать.
Ожидать же от бизнеса понимания в данной ситуации — все равно что ожидать этого же понимания от того, кто будет реализовывать проект. Они все способны совершить одну и ту же ошибку. То есть, тому кто осознает ошибку и пытается ее корректировать, придется отстаивать свою позицию и соответствующие действия. Чтобы это не было досадной необходимостью по факту, нужно осознавать это как обязательные условия изначально.
Еще одно небольшое дополнение. Утверждение «Планируйте выбросить первую версию — вам все равно придется это сделать, потому что она не удовлетворит ожидания пользователей» реализовано в виде приема у некоторых писателей и, особенно, у переводчиков. Специалист начинает работать над текстом, продвигается от начала к концу, и в финале отбрасывает начало (возможно, и середина), и делает его заново. В основе приема лежит простое явление: в начале работы специалист еще не знаком с материалом над которым работает (переводимый текст, создаваемый сюжет). И это относится к типовым задачам в данных отраслях. Если же повысить планку, то многие классические литературные произведения переписывались более одного раза.
Спасибо за подробный комментарий! Я не совсем уверен, спорите ли вы со мной или дополняете, тем не менее, один момент кажется мне очень важным.
1. Безусловно многие из нас делают ошибки путая достаточно определенные и предсказуемые работы и новые, непредсказуемые, для которые оценки основанные на предыдущем опыте не работают.
2. Тем не менее, часто мы вполне понимаем что ступаем на terra incognita, и в лучшем случае мы можем оценить сроки и бюджет с ошибкой в 6-10 раз.
3. Я ни в коем случае не пытаюсь апеллировать к тому чтобы бизнес «понял» и «простил» разработку, и «предоставил столько времени и ресурсов сколько разработчики захотят» — во первых такое отношение было бы снисходительным, а во вторых — так дела не делаются.
4. Однако, неопределенность сроков сама по себе никуда не денется, вне зависимости от того кто берет на себя ответственность за соблюдение сроков которые невозможно гарантировать.
5. Это проблема, и со стороны бизнеса можно ее игнорировать, а можно пойти навстречу разработке.
Ожидать же от бизнеса понимания в данной ситуации — все равно что ожидать...
1. Безусловно многие из нас делают ошибки путая достаточно определенные и предсказуемые работы и новые, непредсказуемые, для которые оценки основанные на предыдущем опыте не работают.
2. Тем не менее, часто мы вполне понимаем что ступаем на terra incognita, и в лучшем случае мы можем оценить сроки и бюджет с ошибкой в 6-10 раз.
3. Я ни в коем случае не пытаюсь апеллировать к тому чтобы бизнес «понял» и «простил» разработку, и «предоставил столько времени и ресурсов сколько разработчики захотят» — во первых такое отношение было бы снисходительным, а во вторых — так дела не делаются.
4. Однако, неопределенность сроков сама по себе никуда не денется, вне зависимости от того кто берет на себя ответственность за соблюдение сроков которые невозможно гарантировать.
5. Это проблема, и со стороны бизнеса можно ее игнорировать, а можно пойти навстречу разработке.
Надо сравнивать сравнимые показатели. OS/360 — пример первого Enterprise программного продукта. И сравнивать его надо с такими же крупными промышленными решениями. Так вот, в таких решениях изменилось мало что за эти десятилетия. Так же невозможно точно планировать, так же сложно управлять огромным коллективом, так же есть проблема обманутых ожиданий и т.п.
Спринты на 2 недели — отличное решение для небольших или архитектурно простых проектов. Или для наращивания функционала в крупном сложном проекте после стабилизации основных механизмов. Но для разработки этих самых основных механизмов требуется другой подход. И работа с крупным клиентом с тысячами требований радикально отличается от работы с клиентом с десятками требований.
Спринты на 2 недели — отличное решение для небольших или архитектурно простых проектов. Или для наращивания функционала в крупном сложном проекте после стабилизации основных механизмов. Но для разработки этих самых основных механизмов требуется другой подход. И работа с крупным клиентом с тысячами требований радикально отличается от работы с клиентом с десятками требований.
Спасибо за комментарий, но пожалуй я вам возражу. Одна из идей которую я хотел
раскрыть состоит в том что не имеет значения «тип» проекта, как вы говорите.
Возможность или невозможность осуществить предсказуемое планирование
определяется тем, — выполняются ли для того необходимые условия.
Более того, решение многих задач для профессионалов может быть вполне рутинной,
планируемой работой. Однако, если лично вы не обладаете необходимой экспертизой
и работа, по какой то причине, досталась лично вам — вы попадаете в область непредсказуемого, соответственно и планирование становится невозможным.
раскрыть состоит в том что не имеет значения «тип» проекта, как вы говорите.
Возможность или невозможность осуществить предсказуемое планирование
определяется тем, — выполняются ли для того необходимые условия.
Более того, решение многих задач для профессионалов может быть вполне рутинной,
планируемой работой. Однако, если лично вы не обладаете необходимой экспертизой
и работа, по какой то причине, досталась лично вам — вы попадаете в область непредсказуемого, соответственно и планирование становится невозможным.
Есть вопросы, который каждый управленец открывает для себя сам. Это вопросы с сакральным смыслом, искать консенсус по ним бессмысленно (и правильного ответа на эти вопросы просто нет):
— Надо ли все проекты вести по одной методологии?
— Должен ли менеджер быть специалистом?
— Кнут или пряник?
— Точное планирование или главное ввязаться?
— Эджайлый скрам наше все или нет?
— Можно ли ядро банковский системы написать на php?
— И пр.
(Вопроса, надо ли врать заказчику при оценке проекта я не пишу, поскольку очевидно, что врать).
У Брукса на подобные вопросы дан какой-либо ответ. С этим ответом можно соглашаться или нет, это ничего не меняет. Вообще, такие производственные мемуары нужны чтобы задуматься, а не искать ответ. В конце концов, можно вылепить Апполона из пенопласта ножовкой по металлу, но в программных проектах трудно сказать, какой метод работы правильный, а какой анекдотичен (предполагаю, что очень много программных проектов сделаны таким методом, просто им повезло).
— Надо ли все проекты вести по одной методологии?
— Должен ли менеджер быть специалистом?
— Кнут или пряник?
— Точное планирование или главное ввязаться?
— Эджайлый скрам наше все или нет?
— Можно ли ядро банковский системы написать на php?
— И пр.
(Вопроса, надо ли врать заказчику при оценке проекта я не пишу, поскольку очевидно, что врать).
У Брукса на подобные вопросы дан какой-либо ответ. С этим ответом можно соглашаться или нет, это ничего не меняет. Вообще, такие производственные мемуары нужны чтобы задуматься, а не искать ответ. В конце концов, можно вылепить Апполона из пенопласта ножовкой по металлу, но в программных проектах трудно сказать, какой метод работы правильный, а какой анекдотичен (предполагаю, что очень много программных проектов сделаны таким методом, просто им повезло).
надо ли врать заказчику при оценке проекта я не пишу, поскольку очевидно, что врать
А вы тоже используете две джиры, одну для разработчиков, другую для заказчиков? ;)
А если серьезно, следующее все же не соответствует действительности.
У Брукса на подобные вопросы дан какой-либо ответ.
Книга Брукса это список проблем нежели решений, более того, сам Брукс систематизировал их в список из двух сотен утверждений требующих критики.
Более того, сам Брукс сетует что получил слишком мало критики на свою книгу.
А вы тоже используете две джиры, одну для разработчиков, другую для заказчиков? ;)
Не джиру и не две, но мысль пошла в этом направлении ;-)
Книга Брукса это список проблем нежели решений, более того, сам Брукс систематизировал их в список из двух сотен утверждений требующих критики.
Наверно вы правы. Я читал книгу довольно давно, и в памяти остались именно варианты решений проектных вопросов. Возможно, это было додумано мною при чтении, возможно, какие-либо ответы в книге есть. Собственно, даже если то, что осталось в памяти, это моё понимание вопросов, поднятых в книге, то книга свою задачу полностью выполнила — стимулировала мышление.
Сколько масштабных и сложных проектов реализовали вы, чтобы вот так критиковать Брукса? Где можно почитать ваши книги?
Книгу можно назвать скорее классикой фольклора разработки, нежели реальным руководством по построению рабочего процесса.Очень сильное заявление. Если уж вы взялись оппонировать Бруксу, то дайте рецензию на его книгу, в чем вы с ним согласны, а в чем нет.
Честно сказать, если бы я прочитал статью до прочтения книги — у меня бы вряд ли возникло желание читать ее.
Вы берете цитаты Брукса и грамотно аргументируете, почему они не верны. Правда в самих цитатах некоторые неточности.
Например:
Под спойлером, автор опираясь на чужие исследования делает вывод, что это не всегда так
Этот вопрос не совсем к Бруксу. Во втором издании есть разъяснение. Вторая система и вторая версия системы — разные вещи.
В общем, тем, кто не читал, все же советую. Это классика, которую можно и читать и перечитывать. Не задаваться вопросом, «Прав ли автор!?», а просто анализировать, что же изменилось спустя 20, 50 или даже 100 лет.
Вы берете цитаты Брукса и грамотно аргументируете, почему они не верны. Правда в самих цитатах некоторые неточности.
Например:
Самые лучшие программисты-профессионалы в 10 раз продуктивнее слабых.
Под спойлером, автор опираясь на чужие исследования делает вывод, что это не всегда так
Глава 3. «Операционная бригада»
В одном из исследований Сакман (Sackman), Эриксон (Erikson) и Грант (Grant) измеряли производительность труда в группе опытных программистов. Внутри одной лишь этой группы соотношение между лучшими и худшими результатами составило примерно 10:1 по производительности труда и 5:1 по скорости работы программ и требуемой для них памяти! Короче, программист, зарабатывающий 20 тысяч долларов в год, может быть в десять раз продуктивнее программиста, зарабатывающего 10 тысяч долларов. Правда, возможно и обратное. Полученные данные не выявили какой-либо корреляции между стажем работы и производительностью. (Я не уверен, что это всегда справедливо.)
Получается, что-то дельное может выйти только с третьего раза? Нет. В определенном смысле Брукс прав, но мы научились с этим справляться.
Этот вопрос не совсем к Бруксу. Во втором издании есть разъяснение. Вторая система и вторая версия системы — разные вещи.
Глава 19 «Мифический человеко-месяц» двадцать лет спустя.
Как насчет эффекта второй системы? Один наблюдательный ученый заметил, что «Мифический человеко-месяц» рекомендовал на случай неудачи для всякой новой системы планировать поставку второй версии (см. глава 11), которая в главе 5 характеризуется как таящая наибольшие опасности. Я вынужден был признать, что он меня «поймал».
Противоречие скорее лингвистическое, чем реальное. «Вторая» система, описываемая в главе 5, — это вторая система, выпускаемая в развитие предыдущей с привлечением дополнительных функций и украшений. «Вторая» система в главе 11 — это вторая попытка разработки первой выпускаемой системы. Она разрабатывается в условиях всех ограничений, накладываемых графиком, способностями и неведением, характерными для новых проектов — ограничений, навязывающих дисциплину умеренности.
Противоречие скорее лингвистическое, чем реальное. «Вторая» система, описываемая в главе 5, — это вторая система, выпускаемая в развитие предыдущей с привлечением дополнительных функций и украшений. «Вторая» система в главе 11 — это вторая попытка разработки первой выпускаемой системы. Она разрабатывается в условиях всех ограничений, накладываемых графиком, способностями и неведением, характерными для новых проектов — ограничений, навязывающих дисциплину умеренности.
В общем, тем, кто не читал, все же советую. Это классика, которую можно и читать и перечитывать. Не задаваться вопросом, «Прав ли автор!?», а просто анализировать, что же изменилось спустя 20, 50 или даже 100 лет.
Большое спасибо за детальный комментарий.
Согласен с вам, не смотря на то что некоторые главы откровенно устарели,
в целом книга вполне актуальна. Мы продолжаем сталкиваться с теми же проблемами
и совершать те же ошибки.
Согласен с вам, не смотря на то что некоторые главы откровенно устарели,
в целом книга вполне актуальна. Мы продолжаем сталкиваться с теми же проблемами
и совершать те же ошибки.
"Люди как люди. Любят деньги, но ведь это всегда было… Человечество любит деньги, из чего бы те ни были сделаны, из кожи ли, из бумаги ли, из бронзы или из золота. Ну, легкомысленны… ну, что ж… и милосердие иногда стучится в их сердца… обыкновенные люди… в общем, напоминают прежних… квартирный вопрос только испортил их…"
del
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Фактический человеко-месяц