Comments on: О вреде излишнего планирования http://alexlebedev.com/blog/%d0%be-%d0%b2%d1%80%d0%b5%d0%b4%d0%b5-%d0%b8%d0%b7%d0%bb%d0%b8%d1%88%d0%bd%d0%b5%d0%b3%d0%be-%d0%bf%d0%bb%d0%b0%d0%bd%d0%b8%d1%80%d0%be%d0%b2%d0%b0%d0%bd%d0%b8%d1%8f/ Alexander Lebedev writes about software development and outsourcing Tue, 16 Feb 2010 17:27:57 -0800 http://wordpress.org/?v=2.8.4 hourly 1 By: Ian Kyrychenko http://alexlebedev.com/blog/%d0%be-%d0%b2%d1%80%d0%b5%d0%b4%d0%b5-%d0%b8%d0%b7%d0%bb%d0%b8%d1%88%d0%bd%d0%b5%d0%b3%d0%be-%d0%bf%d0%bb%d0%b0%d0%bd%d0%b8%d1%80%d0%be%d0%b2%d0%b0%d0%bd%d0%b8%d1%8f/comment-page-1/#comment-19508 Ian Kyrychenko Thu, 04 Sep 2008 10:28:06 +0000 http://alexlebedev.com/blog/%d0%be-%d0%b2%d1%80%d0%b5%d0%b4%d0%b5-%d0%b8%d0%b7%d0%bb%d0%b8%d1%88%d0%bd%d0%b5%d0%b3%d0%be-%d0%bf%d0%bb%d0%b0%d0%bd%d0%b8%d1%80%d0%be%d0%b2%d0%b0%d0%bd%d0%b8%d1%8f/#comment-19508 <p>Ну, тут возразить нечего)</p> Ну, тут возразить нечего)

]]> By: Alex Lebedev http://alexlebedev.com/blog/%d0%be-%d0%b2%d1%80%d0%b5%d0%b4%d0%b5-%d0%b8%d0%b7%d0%bb%d0%b8%d1%88%d0%bd%d0%b5%d0%b3%d0%be-%d0%bf%d0%bb%d0%b0%d0%bd%d0%b8%d1%80%d0%be%d0%b2%d0%b0%d0%bd%d0%b8%d1%8f/comment-page-1/#comment-19197 Alex Lebedev Fri, 29 Aug 2008 13:21:20 +0000 http://alexlebedev.com/blog/%d0%be-%d0%b2%d1%80%d0%b5%d0%b4%d0%b5-%d0%b8%d0%b7%d0%bb%d0%b8%d1%88%d0%bd%d0%b5%d0%b3%d0%be-%d0%bf%d0%bb%d0%b0%d0%bd%d0%b8%d1%80%d0%be%d0%b2%d0%b0%d0%bd%d0%b8%d1%8f/#comment-19197 <p>To Ian Kyrychenko:</p> <p>Да, постоянное исправление планов согласно происходящим изменениям разумно. Начиная от определенного размера проекта (ИМХО, человек 10-12) начинает становиться еще и оправданным, то есть приносит пользы больше, чем забирает усилий.</p> <p>Но писал я не про это. Писал я про илюзию того, что если план составить, то события магическим образом будут этому плану соответствовать:</p> <blockquote> <p>Регулярно сталкиваюсь с желанием того или иного руководства составить подробный план работ и строго следовать ему.</p> </blockquote> To Ian Kyrychenko:

Да, постоянное исправление планов согласно происходящим изменениям разумно. Начиная от определенного размера проекта (ИМХО, человек 10-12) начинает становиться еще и оправданным, то есть приносит пользы больше, чем забирает усилий.

Но писал я не про это. Писал я про илюзию того, что если план составить, то события магическим образом будут этому плану соответствовать:

Регулярно сталкиваюсь с желанием того или иного руководства составить подробный план работ и строго следовать ему.

]]> By: Ian Kyrychenko http://alexlebedev.com/blog/%d0%be-%d0%b2%d1%80%d0%b5%d0%b4%d0%b5-%d0%b8%d0%b7%d0%bb%d0%b8%d1%88%d0%bd%d0%b5%d0%b3%d0%be-%d0%bf%d0%bb%d0%b0%d0%bd%d0%b8%d1%80%d0%be%d0%b2%d0%b0%d0%bd%d0%b8%d1%8f/comment-page-1/#comment-19196 Ian Kyrychenko Fri, 29 Aug 2008 13:08:08 +0000 http://alexlebedev.com/blog/%d0%be-%d0%b2%d1%80%d0%b5%d0%b4%d0%b5-%d0%b8%d0%b7%d0%bb%d0%b8%d1%88%d0%bd%d0%b5%d0%b3%d0%be-%d0%bf%d0%bb%d0%b0%d0%bd%d0%b8%d1%80%d0%be%d0%b2%d0%b0%d0%bd%d0%b8%d1%8f/#comment-19196 <p>Хм, во всех этих размышлениях есть небольшая неточность. Ни в одной книге либо документации по проджект менеджменту вы не найдете слов - создали план - засуньте его под стекло и руководствуйтесь только им. И в классике <b>PMBOK</b>и у Ройса - везде вы найдете среди обязательных процесов один самый важный - <b>внесение изменений во все планы, которые вы создали для данного проэкта в соответствии с теущим положением вещей</b>. Без четкого планирования можно упустить контроль за изменениями и, фактически, не фиксировать для себя качественно и количественно эти самые изминения.</p> Хм, во всех этих размышлениях есть небольшая неточность. Ни в одной книге либо документации по проджект менеджменту вы не найдете слов – создали план – засуньте его под стекло и руководствуйтесь только им. И в классике PMBOKи у Ройса – везде вы найдете среди обязательных процесов один самый важный – внесение изменений во все планы, которые вы создали для данного проэкта в соответствии с теущим положением вещей. Без четкого планирования можно упустить контроль за изменениями и, фактически, не фиксировать для себя качественно и количественно эти самые изминения.

]]> By: Alex Lebedev http://alexlebedev.com/blog/%d0%be-%d0%b2%d1%80%d0%b5%d0%b4%d0%b5-%d0%b8%d0%b7%d0%bb%d0%b8%d1%88%d0%bd%d0%b5%d0%b3%d0%be-%d0%bf%d0%bb%d0%b0%d0%bd%d0%b8%d1%80%d0%be%d0%b2%d0%b0%d0%bd%d0%b8%d1%8f/comment-page-1/#comment-8 Alex Lebedev Tue, 08 Aug 2006 13:19:19 +0000 http://alexlebedev.com/blog/%d0%be-%d0%b2%d1%80%d0%b5%d0%b4%d0%b5-%d0%b8%d0%b7%d0%bb%d0%b8%d1%88%d0%bd%d0%b5%d0%b3%d0%be-%d0%bf%d0%bb%d0%b0%d0%bd%d0%b8%d1%80%d0%be%d0%b2%d0%b0%d0%bd%d0%b8%d1%8f/#comment-8 <p>Никто из нас не самый главный менеджер, это нормально. Нужно осознавать, что определенное неудобство от инициатив вышестоящего руководства всегда будет исходить. У руководства свои цели, которые никогда полностью не совпадают с нашими целями. Что делать если начальство требует подробный план, добавить в проект никому не нужных Васю и Петю, портировать все на Java, быть телепатом, стоять на голове по утрам (нужное подчеркнуть)? Есть много вариантов: - Реконструировать то, чего пытается добиться руководство и предложить менее болезненный способ. - Принимать удар на себя и ограждать разработчиков. Спорить, делать липовые отчеты, изолировать Васю и Петю на второстепенном участке проекта. - Подчиниться и пофилософствовать на тему того что мир не идеален. - Если это совсем невыносимо, свалить из проекта или компании. Я уже писал про то, что разгребание последствий чужих ошибок - вещь неблагодарная и малополезная для профессионального роста.</p> <p>Еще один момент - качество работы менеджера зависит от того, как хорошо сработала команда, а не от того сколько раз вы сказали "да" дурацким идеям руководства. Об этом стоить помнить при принятии решений. Получается типичная задача на оптимизацию - получить максимальный результат, не испортив при этом отношения с руководством. Как именно это сделать - смотри по ситуации.</p> <blockquote> ... как выпустить наиболее функциональный и наименее глючный продукт к определенному сроку? </blockquote> <p>Чтобы выпустить наиболее функциональный и наименее глючный продукт нужно обеспечить разработчикам спокойную обстановку и четкие приоритеты. Если срок близко, то можно усилить на неделю-две интенсивность работы, иногда это оправданно. Насколько возможно, экранировать плохие идеи руководства и другие источники раздражения. Не отвлекать текущими проблемами у заказчиков всех разработчиков, а начинать с одного. В общем, делать все то же, что нужно делать и при создании хорошего процесса разработки. И быть готовым творчески подходить к функциональности продукта и срокам выпуска.</p> Никто из нас не самый главный менеджер, это нормально. Нужно осознавать, что определенное неудобство от инициатив вышестоящего руководства всегда будет исходить. У руководства свои цели, которые никогда полностью не совпадают с нашими целями. Что делать если начальство требует подробный план, добавить в проект никому не нужных Васю и Петю, портировать все на Java, быть телепатом, стоять на голове по утрам (нужное подчеркнуть)? Есть много вариантов:
- Реконструировать то, чего пытается добиться руководство и предложить менее болезненный способ.
- Принимать удар на себя и ограждать разработчиков. Спорить, делать липовые отчеты, изолировать Васю и Петю на второстепенном участке проекта.
- Подчиниться и пофилософствовать на тему того что мир не идеален.
- Если это совсем невыносимо, свалить из проекта или компании. Я уже писал про то, что разгребание последствий чужих ошибок – вещь неблагодарная и малополезная для профессионального роста.

Еще один момент – качество работы менеджера зависит от того, как хорошо сработала команда, а не от того сколько раз вы сказали “да” дурацким идеям руководства. Об этом стоить помнить при принятии решений. Получается типичная задача на оптимизацию – получить максимальный результат, не испортив при этом отношения с руководством. Как именно это сделать – смотри по ситуации.

… как выпустить наиболее функциональный и наименее глючный продукт к определенному сроку?

Чтобы выпустить наиболее функциональный и наименее глючный продукт нужно обеспечить разработчикам спокойную обстановку и четкие приоритеты. Если срок близко, то можно усилить на неделю-две интенсивность работы, иногда это оправданно. Насколько возможно, экранировать плохие идеи руководства и другие источники раздражения. Не отвлекать текущими проблемами у заказчиков всех разработчиков, а начинать с одного. В общем, делать все то же, что нужно делать и при создании хорошего процесса разработки. И быть готовым творчески подходить к функциональности продукта и срокам выпуска.

]]> By: Victoria http://alexlebedev.com/blog/%d0%be-%d0%b2%d1%80%d0%b5%d0%b4%d0%b5-%d0%b8%d0%b7%d0%bb%d0%b8%d1%88%d0%bd%d0%b5%d0%b3%d0%be-%d0%bf%d0%bb%d0%b0%d0%bd%d0%b8%d1%80%d0%be%d0%b2%d0%b0%d0%bd%d0%b8%d1%8f/comment-page-1/#comment-7 Victoria Tue, 08 Aug 2006 08:35:44 +0000 http://alexlebedev.com/blog/%d0%be-%d0%b2%d1%80%d0%b5%d0%b4%d0%b5-%d0%b8%d0%b7%d0%bb%d0%b8%d1%88%d0%bd%d0%b5%d0%b3%d0%be-%d0%bf%d0%bb%d0%b0%d0%bd%d0%b8%d1%80%d0%be%d0%b2%d0%b0%d0%bd%d0%b8%d1%8f/#comment-7 <p>Да, все хорошо. У меня только есть пара вопросов. Что делать, если ты не самый-самый главный менеджер в организации, а подробных планов и регламента от тебя требует руководство или там корпоративная культура? Делать двойную работу, составляя два плана или пытаться "убедить руководство", что так планировать неправильно? Другой вопрос - назначена точная дата выпуска (по-разным причинам - заказчики, потребители требуют), так как выпустить наиболее функциональный и наименее глючный продукт к определенному сроку?</p> Да, все хорошо. У меня только есть пара вопросов.
Что делать, если ты не самый-самый главный менеджер в организации, а подробных планов и регламента от тебя требует руководство или там корпоративная культура? Делать двойную работу, составляя два плана или пытаться “убедить руководство”, что так планировать неправильно?
Другой вопрос – назначена точная дата выпуска (по-разным причинам – заказчики, потребители требуют), так как выпустить наиболее функциональный и наименее глючный продукт к определенному сроку?

]]>