Комментарии 32
«а пока проект не укладывается в сроки рассказываем заказчикам сказки» :)
проблема не столько в том, что мы пытаемся сократить время, опуская какие-то шаги, сколько в том, что мы не знаем, сколько времени займет «приготовление» продукта — отсюда и срывы сроков, установленных «от балды».
проблема не столько в том, что мы пытаемся сократить время, опуская какие-то шаги, сколько в том, что мы не знаем, сколько времени займет «приготовление» продукта — отсюда и срывы сроков, установленных «от балды».
В этом плане Уинберг, конечно, берет идеальную ситуацию — «Знаем, что надо сделать, знаем, как надо сделать, знаем, когда сможем сделать, но заказчик противная злюка».
Мне тут очень нравится сама мораль про «не бойся делать то, что правильно».
Мне тут очень нравится сама мораль про «не бойся делать то, что правильно».
но все относительно, к сожалению (или к счастью?)
возьмем такой пример:
есть ТЗ, по нему разработчики должны сделать систему.
Как водится, сроки не реальны, а выпуск затягивается. Такое положение вещей известно заказчику, и он готов внедрить и использовать ту часть, которая будет реализована к сроку, а остальное будет внедрено через некоторое время по мене готовности продукта.
будет ли менеджер в данном случае перечить заказчику и не отдавать «недопеченый» продукт? наверно, нет. хотя отдавать неготовую систему не очень-то «правильно».
возьмем такой пример:
есть ТЗ, по нему разработчики должны сделать систему.
Как водится, сроки не реальны, а выпуск затягивается. Такое положение вещей известно заказчику, и он готов внедрить и использовать ту часть, которая будет реализована к сроку, а остальное будет внедрено через некоторое время по мене готовности продукта.
будет ли менеджер в данном случае перечить заказчику и не отдавать «недопеченый» продукт? наверно, нет. хотя отдавать неготовую систему не очень-то «правильно».
Я бы не сказал, что это «неправильно» — качество готового функционала, судя по всему, удовлетворяет заказчика.
В этом случае сказку можно модифицировать следующим образом: вместо пирога будет печенье, а за отведенное время можно приготовить только один протвинь, а не нужные два. И смысл останется примерно тот же. :)
В этом случае сказку можно модифицировать следующим образом: вместо пирога будет печенье, а за отведенное время можно приготовить только один протвинь, а не нужные два. И смысл останется примерно тот же. :)
«хотя отдавать неготовую систему не очень-то «правильно»»
Да нет, это как раз нормально — для этого и используются (в ИТ) адаптивные подходы и короткие итерации. Такой подход должен принять на вооружение (ну а как минимум — во внимание) каждый современный менеджер ИТ-проекта.
Да нет, это как раз нормально — для этого и используются (в ИТ) адаптивные подходы и короткие итерации. Такой подход должен принять на вооружение (ну а как минимум — во внимание) каждый современный менеджер ИТ-проекта.
Но ведь, исходя из постоянной практики не реальных сроков и затягивающихся выпусков, можно заранее продумать минимальный функционал, который устроил бы клиента и запускать проект версиями — первая, вторая и так далее. Опять же вопрос не столько тестирования, сколько грамотной работы менеджера.
а это называется итеративная разработка, и она применяется часто. Этот подход гарантирует, что мы получим рабочий продукт раньше, и при этом заказчик получит то, что хоть как-то, но решает его задачи.
но по опыту могу сказать, что проблему затягивания сроков даже этот подход полностью не решает: если в одной итерации что-то не успели сделать, то планирование нескольких последующих итераций (в идеале — одной) придется менять.
но по опыту могу сказать, что проблему затягивания сроков даже этот подход полностью не решает: если в одной итерации что-то не успели сделать, то планирование нескольких последующих итераций (в идеале — одной) придется менять.
Опять же вопрос не столько тестирования, сколько грамотной работы менеджера.
Тестирование для Уинберга — это больная тема, поэтому он про него во вступлении и говорит.
А так его можно заменить любым процессом, без которого гарантировать качество становится проблематично — планированием, управлением рисками и т.п.
Соглашусь, в отличии от пирога, в программировании нет идеальных рецептов и сроков, по этому при приблизительной оценки «идеального» срока, надо учитывать слишком много факторов…
Agile-мудрая-дикобразиха выдала бы королеве начинки по-отдельности. Потом — испеченное «тело» пирога. К тому времени принцесса, которая обожралась варенья и сахара по-отдельности, сказала бы «Спасибо, больше не могу!»
Был бы рулез :)
Был бы рулез :)
Во время чтения, вспомнилась мне история создания продукта «Галактика».
Вот только так и не определился, кто из зверей больше всего подходит на автора сего продукта :)
Вот только так и не определился, кто из зверей больше всего подходит на автора сего продукта :)
Черт возьми, это просто квинтессенция сути большинства современных айтишных проектов!!! :)
За исключением того, что первые три неудачника безуспешно пробовали бы доделывать свои пироги лишний час :)
За исключением того, что первые три неудачника безуспешно пробовали бы доделывать свои пироги лишний час :)
Мне понравился подход. Хотя он используется во всех сказках и баснях: проекция реальной жизни на мир фантазии, доступный и понятный.
Королевы всегда говорят «Мы», потому что думают, что говорят от имени целого народа.Замечательная метафора!
Проблема не в желании уложиться в срок за счет урезания тестирования. Скорее проблема в изначально неправильном определении сроков по причине либо невнятности ТЗ, либо игнорирования прогнозов разработчиков, либо в не полной мере описанных заказчиком хотелок.
Как показывает практика, заказчики далеко не всегда способны в полной мере описать свои хотелки. В случае хотелок заказчика часто требуется собстенный опыт разработчиков и заранее спланированная и заложенная в бюджет и срок работ подушка безопасности под названием «доработка проекта», как правило составляющая 20-25% от общей стоимости и сроков работ.
«весело смеялась, жалобно плакала и от души хлопала в ладоши» менеджеру просто необходимо быть артистом ансамбля «творчества и плясок», я считаю, одного бубна явно будет недостаточно. Для меня мораль сей басни такова что менеджер и разработчик должны сотрудничать и решать проблемы совместно, не пытаясь выехат за счет других, тогда все будет ок.
откровенно в тему, но королеве пришлось пребывать целый час в ожидании пирога и тратить заветные «златые»…
проще было заранее ей сказать, что же ее будет ждать когда она приедет )
проще было заранее ей сказать, что же ее будет ждать когда она приедет )
Похоже в этой статье был использован прием «тройная спираль» из нлп, про который я раньше где-то читал.
Вы написали статью про человека который рассказывал сказку некой Камилле про Дикобразиху, которая рассказывала сказку королеве про принцессу и горошину. НЛП утверждает что вложенная таким образом информация пойдет напрямую в подсознание, потому что сознание перестает нормально ориентироваться во всех этих вложенных друг в друга сказках.
Вы написали статью про человека который рассказывал сказку некой Камилле про Дикобразиху, которая рассказывала сказку королеве про принцессу и горошину. НЛП утверждает что вложенная таким образом информация пойдет напрямую в подсознание, потому что сознание перестает нормально ориентироваться во всех этих вложенных друг в друга сказках.
да я понимаю, что это всего лишь метафора, но все же: очень противоречивые ощущения вызывает эта сказка. Подано все очень красиво, но несколько ключевых моментов в сказке, которые у меня вызывают «отторжение»:
— королева заказала испечь пирог одновременно нескольким поварам. В реальной жизни скорее всего заказчик не может себе такого позволить, как бы богат и влиятелен он не был
— королева и все повара четко знали — каким должен быть пирог на цвет/консистенцию/вкус (т.е. требования к конечному продукту были настолько точными, что даже никак не обсуждались). согласитесь что в жизни такого практически не бывает, определить «чем же плох пирог» заказчик сможет только по прошествии времени и получения реального опыта «поедания плохого пирога»
— у королевы была возможность сравнить неудачные варианты и сразу же их отбросить, как негодные. В реальной жизни она была бы вынуждена тратить время и ресурсы на допекание одного из «неудачных пирогов». И уж тем более не смогла бы понять, что дикообразиха способна выдать лучший продукт, потратив чуть больше времени, чем другие претенденты уложившиеся в выделенное время.
— и главное мораль сказки «Если ты боишься делать то, что кажется тебе правильным, то ты не настоящий пекарь», т.е. иными словами «заказчик глуп, требуя сократить сроки, стой на своем — если веришь в себя!». Практически главный постулат дизайнерской культуры — по моему это ключ к понимаю направления мыслей автора.
— королева заказала испечь пирог одновременно нескольким поварам. В реальной жизни скорее всего заказчик не может себе такого позволить, как бы богат и влиятелен он не был
— королева и все повара четко знали — каким должен быть пирог на цвет/консистенцию/вкус (т.е. требования к конечному продукту были настолько точными, что даже никак не обсуждались). согласитесь что в жизни такого практически не бывает, определить «чем же плох пирог» заказчик сможет только по прошествии времени и получения реального опыта «поедания плохого пирога»
— у королевы была возможность сравнить неудачные варианты и сразу же их отбросить, как негодные. В реальной жизни она была бы вынуждена тратить время и ресурсы на допекание одного из «неудачных пирогов». И уж тем более не смогла бы понять, что дикообразиха способна выдать лучший продукт, потратив чуть больше времени, чем другие претенденты уложившиеся в выделенное время.
— и главное мораль сказки «Если ты боишься делать то, что кажется тебе правильным, то ты не настоящий пекарь», т.е. иными словами «заказчик глуп, требуя сократить сроки, стой на своем — если веришь в себя!». Практически главный постулат дизайнерской культуры — по моему это ключ к понимаю направления мыслей автора.
Любопытная мысль пришла в голову- если отвязать описанную в сказке метафору от схемы «заказчик-проект-исполнитель», и применить к схеме «конкурсная комиссия-задание-конкурсант» (a-la многочисленные конкурсы для программистов или организумые крупными компаниями для найма), что намного ближе к ее сути (ибо по сюжету — это конкурс), все становится на свои места, но меняется мораль и вывод: при жестком ограничении по времени дикообразиха точно бы не победила, не выполнив главное условие конкурса.
Я не дизайнер, а разработчик, но могу сказать что автор прав — основной причиной просадки проекта как по срокам, так и по качеству является недостаточная тщательность исполнения, которую обосновывают жесткими сроками.
А на деле грубая или даже грязная работа дает строго обратный эффект, так как перегружает все остальные, и без того наиболее трудоемкие стадии выпуска — рецензирование, отладку, тестирование, внедрение и сопровождение.
Парадоксально, но лучший способ попасть в сроки — считать их рекомендацией, а думать прежде всего о качестве решений и исполнения.
Исключение составляют задачи, которые после определенного срока не имеет смысла делать вообще. Это спортивное программирование и написание прототипов, но такой код никогда не должен попасть в релиз (лучше всего — выкинут сразу после демонстрации).
А на деле грубая или даже грязная работа дает строго обратный эффект, так как перегружает все остальные, и без того наиболее трудоемкие стадии выпуска — рецензирование, отладку, тестирование, внедрение и сопровождение.
Парадоксально, но лучший способ попасть в сроки — считать их рекомендацией, а думать прежде всего о качестве решений и исполнения.
Исключение составляют задачи, которые после определенного срока не имеет смысла делать вообще. Это спортивное программирование и написание прототипов, но такой код никогда не должен попасть в релиз (лучше всего — выкинут сразу после демонстрации).
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Сказка о тестировании