Спасибо за фидбэк. Ваше мыло должно оканчиваться на @gmail.com. Если не пускает попробуйте удалить куку с ключом «ACSID» на этой странице и снова пройти по ссылке. Если не поможет отпишите пожалуйста через форму обратной связи.
Ну во первых нужно понять какая модель управления в предприятии. На что она похожа.
Во-вторых понять какой зоопар информационных систем есть. Нам так или иначе нужно будет с ними жить.
В-третьих понять для чего внедряется проектное управление. Быть может просто нанять нормальных проджект менов и дать им бюджет для оргразвития. А как организовывать свою работу это их дело.
Но допустим я менеджер в крупной организацией с большим кол-вом регулярных процессов. Тогда.
Если бы я сегодня начинал проект по внедрению процесного управления то я бы взял BizAgy, там хорошо и гибко можно менять логику и делать ее прозрачной. А всякие аналитики и сводные темы я бы делал в дешевой OLAP системе, вот недавно изучал хороший украинский продукт, можно очень быстро там ваять всяике штуки. Если интересно то вспомню название
Если бы я внедрял проектное управление то я бы начал с системы управления в компании. Построил бы модель. И скорее всего выбрал что-то максимально простое где можно удобно обмениватся информацией по проекту. И вовлекать в проект и заказчиков и подрядчиков. Чтобы без дублежа по почте было. Пока на ум приходит только волна. Но я верю что есть и другие варианты.
Про вовлечение программиста это очень верно. У нас программисты так вовлечены что им все завидуют и чувствуют себя ненужными. У меня руки тоже чешутся, хочется поучаствовать.
Да мы не изобрели ничего нового. Мы просто хотим донести что маниакальное увлечение PERT и WBS может погубить проект. И отвлеч от того что действительно важно. Ну я думаю вы отлично это понимаете.
Вроде понятна ситуация. Ну я опять не вижу проблему в итеративном подходе.
Вы же захотели смайлы много позже чем запустился чат в первоначальном виде.
И чем быстрее вы этот чат бы запустили тем быстрее бы пришло понимание того что и как нужно усовершенстовать. То есть если бы вы не запускали а сидели и продумывали всю широту функциональности то может быть до сих пор бы проектировали огромную махину.
Возможно вас расстраивает то что результата вашего труда нужно выбрасывать. Ну так да. Самое ценное это ведь не код, а вижн продукта или еще можно сказать ТЗ.
Нужно еще добавить что мы тоже 10 лет уже как занимаемся разработкой ПО для букмейкерских контор.
И в нашем первом проекте заказчик не смог сформуровать требования к системе. В итоге мы открыли свою букмейкерку, проанализировали бизнес-процессы и сами написали себе ТЗ. Дальше все случилось как надо:)
И вот на этом примере мы поняли что такое итеративных подход на практике. Сейчас мы дополнили свое понимание объектным подходом
В теории то что вы говорите верно.
На практике же требования проекте все время плывут. Я видел в своей жизни решение когда проектная команда все время обвиняет некое «руководство» и постоянное изменение требований. Вот типо из-за всего этого бардака я нас календарный план плывет.
Ну да круто отмазались. IT-отдел или кто-то там еще не виноват. А если нужно действительно сделать проект как можно быстрее так чтобы заработало на практике? В этом случае чем быстрее вы выкатите полный вижн архитектуры и демонстрацию того как все взаимодействует чем быстрее вы получите уточненные требования.
Да интересная проблема.
Из вашего краткого описания объективный вывод сделать сложно. Я понял что в вашем случае бизнес-логика которая закладывалась изначально оказалась неверной. И после тестирования выяснилось что нужна совсем другая логика.
Если так то ваш пример это просто идеальная иллюстрация выгоды итеративного подхода. Если бы вы решили сразу все сделать то потратили гораздо больше ресурсов, но пришли бы все равно к тому же результату и все нужно было переделывать.
Насколько я понимаю вы еще не совсем удачно использовали итеративный подход. Вы заложили много гибкости надеясь на то что это будет для вас спасением. В результате же оказалось что ваши прогнозы не сбылись. Если бы вы изначально делали еще более тяпляпное решение без излишней гипкости то ввяснили пробблемы несоответствия бизнес-логики и архитектуры гораздо раньше.
в эверноте на больше нельзя дать прямую ссылку на заметку. Или я просто в интерфейсе заблудился. В общем жалко конечно пришлось привыкать к gdocs для телефона.
Я читал как развивался старбакс. Не вижу там противоречий.
По поводу сроков проекта. Никто не говорит что они не нужна. Срок очень даже нужен. Но планирование всего проекта нужно делать не от PERT и WBS, а от архитектуры. Что это дает? Это дает то что уже после первой итерации есть хорошее понимание всех рисков проекта. И соответвенно ключевые ресырсы направляются именно на самые рисковые точки. В результате имеем сильное преимущество перед календарным планированием проекта.
По поводу инвестиций. Конечно если ты береш деньги у государственых фондов которым нужно прикрывать жопу бумажками тебе нужно делать всякие расчеты NPV, IRR и прочее. Но любой грамотный инвестор хорошо понимает что все эти расчеты разбиваются о то что невозмодно грамотно запланировать выручку. Ну за исключением того когда у тебя есть уже известный заказчик и подписан контракт. Но тогда это уже вообще халава. И таже девочка экономист легко справится с расчетами. да именно та же которая для госконтрактов рыбы календарных планов заполняет. У меня есть опыт организации процесса инвестиционного анализа в открывании типовых столовок с известными параметрами контракта и размером дотации. И я очень хорошо понимаю пустопорожнесть трепа про инвестора которому нужны точные суммы. Инвестору нужно чтобы руководитель проекта был грамотный и чтобы этот руководитель проекта сказал: «да сделаем, не ссы».
По поводу госконтрактов. Тут опять все просто. нужно всеголиш больше тратить лаве на девочек и мальчиков которые будут писать эти никому не нужные документа с календарными планами и прочей лабудой. С госзаказчиками на мой взгляд самая сложная работа это как раз переговорное сопровождение продажи. Нужно выявить кто реально принимает решение в этой огромной госмахине. И не одна бутылка коньякак будет выпита пока это будет сделана. Эта задача тоже решается итеративно. Нужно в самом начале проекта начать генерить документы требующие утверждения и следить за их движением. Внутри вашего госзаказчика. И тогда многие скрытые вещи станут явными.
По поводы правды жизни. Тут опять таки я не видел ни одного проекта которые был запланирован через PERT наприсован в диаграммме ганта и эта диаграмма дожила до конце проекта. Если мне такой проект покажут то было бы интересно посмотреть на менеджера. Я пожалуй сразу же ему предложу работу.
Да есть такая тема непоняткой где поднажать и где подзабить.
Я вижу решение этого вопроса так:
— Мы выделяем срок на одну итерацию. на первую итерацию можно выделить например 25% от всего времени.
— И за время итерации делаем весь проект целиком. Естесвтенно делаем его тяпляп. Но зато весь.
— Когда подходим ко второй итерации мы уже гораздо лучше понимаем где поднажать и где подзабить. И второй раз делаем уже более детально. После второй итерации у нас снова есть работающий продукт, с большим кол-вом рбшечек.
Для супер сложных и больших проектов время первой итерации может быть меньше в процентном отношении и быть где-то 5-10%. В маленьких проектах я думаю можно делать в две итерации, и выделать на первую итерацию 40%. Но что такое большой и что такое маленький это все от глазомера естественно зависит:)
А можно услышать суждение? Типо книга такого-то перца клевая, особенно пример про Гитлера, а вот известная книга Льва Толстого о мотивации прочтения не стоит. Ведь реально интересно разобраться в том как мотивировать команду и себя.
Я думаю что проблема лежит немного в другой плоскости. Дело в том что времена ЧеловекСделавшийСебяСам уже прошли. Приходит время команд. Особенно это касается web проектов. Куча всего уже работает и работает в целом нормально.
Для себя я нашел ответ. Как это ни банально звучит, но нужно учится работать в команде. Нужно учится делится знаниями и быть готовым подхватить идеи других людей и принять их в свое сердце.
Каждая «унылая» работа в которой пробовал себя автор топика это был шанс создать что-то в команде. И почему-то про это не сказано ни слова. Почему все эти работы такие унылые? Может быть просто наш герой изначально не искал такую команду с которой будет готов разделить свои идеи, цели, надежды. Вероятно герой гнался за запрлатой или удобным расположением офиса или возможностью свободного графика. Но не искал в глазах босса и коллег отблеск того огня который зажигает звезды.
Как именно найти свою команду я не знаю. Я недавно читал историю Пиксара и мне очень понравилось что художник который в итоге привел компанию к коммерческому успеху в производтсве мультиков просто любил заглядывать к ребытам в офис и хотел немного помоч им с иллюстрациями.
Собственно в мире нет недостатка идей. Идей сейчас очень много и очень много действительно хороших. А вот недостаток команд ощущается очень остро.
Не так сложно же было сделать из статьи вывод в виде основной мысли и назвать им статью. А то эти пять способов заработать миллион уже приелись.
На вскидку можно назвать так: «Договариваемся на берегу или как не потерять заказчика». Но это я вывод сделал за автора. Может ваша мысль она другая все-таки
Во-вторых понять какой зоопар информационных систем есть. Нам так или иначе нужно будет с ними жить.
В-третьих понять для чего внедряется проектное управление. Быть может просто нанять нормальных проджект менов и дать им бюджет для оргразвития. А как организовывать свою работу это их дело.
Но допустим я менеджер в крупной организацией с большим кол-вом регулярных процессов. Тогда.
Если бы я сегодня начинал проект по внедрению процесного управления то я бы взял BizAgy, там хорошо и гибко можно менять логику и делать ее прозрачной. А всякие аналитики и сводные темы я бы делал в дешевой OLAP системе, вот недавно изучал хороший украинский продукт, можно очень быстро там ваять всяике штуки. Если интересно то вспомню название
Если бы я внедрял проектное управление то я бы начал с системы управления в компании. Построил бы модель. И скорее всего выбрал что-то максимально простое где можно удобно обмениватся информацией по проекту. И вовлекать в проект и заказчиков и подрядчиков. Чтобы без дублежа по почте было. Пока на ум приходит только волна. Но я верю что есть и другие варианты.
Вы же захотели смайлы много позже чем запустился чат в первоначальном виде.
И чем быстрее вы этот чат бы запустили тем быстрее бы пришло понимание того что и как нужно усовершенстовать. То есть если бы вы не запускали а сидели и продумывали всю широту функциональности то может быть до сих пор бы проектировали огромную махину.
Возможно вас расстраивает то что результата вашего труда нужно выбрасывать. Ну так да. Самое ценное это ведь не код, а вижн продукта или еще можно сказать ТЗ.
И в нашем первом проекте заказчик не смог сформуровать требования к системе. В итоге мы открыли свою букмейкерку, проанализировали бизнес-процессы и сами написали себе ТЗ. Дальше все случилось как надо:)
И вот на этом примере мы поняли что такое итеративных подход на практике. Сейчас мы дополнили свое понимание объектным подходом
На практике же требования проекте все время плывут. Я видел в своей жизни решение когда проектная команда все время обвиняет некое «руководство» и постоянное изменение требований. Вот типо из-за всего этого бардака я нас календарный план плывет.
Ну да круто отмазались. IT-отдел или кто-то там еще не виноват. А если нужно действительно сделать проект как можно быстрее так чтобы заработало на практике? В этом случае чем быстрее вы выкатите полный вижн архитектуры и демонстрацию того как все взаимодействует чем быстрее вы получите уточненные требования.
Из вашего краткого описания объективный вывод сделать сложно. Я понял что в вашем случае бизнес-логика которая закладывалась изначально оказалась неверной. И после тестирования выяснилось что нужна совсем другая логика.
Если так то ваш пример это просто идеальная иллюстрация выгоды итеративного подхода. Если бы вы решили сразу все сделать то потратили гораздо больше ресурсов, но пришли бы все равно к тому же результату и все нужно было переделывать.
Насколько я понимаю вы еще не совсем удачно использовали итеративный подход. Вы заложили много гибкости надеясь на то что это будет для вас спасением. В результате же оказалось что ваши прогнозы не сбылись. Если бы вы изначально делали еще более тяпляпное решение без излишней гипкости то ввяснили пробблемы несоответствия бизнес-логики и архитектуры гораздо раньше.
По поводу сроков проекта. Никто не говорит что они не нужна. Срок очень даже нужен. Но планирование всего проекта нужно делать не от PERT и WBS, а от архитектуры. Что это дает? Это дает то что уже после первой итерации есть хорошее понимание всех рисков проекта. И соответвенно ключевые ресырсы направляются именно на самые рисковые точки. В результате имеем сильное преимущество перед календарным планированием проекта.
По поводу инвестиций. Конечно если ты береш деньги у государственых фондов которым нужно прикрывать жопу бумажками тебе нужно делать всякие расчеты NPV, IRR и прочее. Но любой грамотный инвестор хорошо понимает что все эти расчеты разбиваются о то что невозмодно грамотно запланировать выручку. Ну за исключением того когда у тебя есть уже известный заказчик и подписан контракт. Но тогда это уже вообще халава. И таже девочка экономист легко справится с расчетами. да именно та же которая для госконтрактов рыбы календарных планов заполняет. У меня есть опыт организации процесса инвестиционного анализа в открывании типовых столовок с известными параметрами контракта и размером дотации. И я очень хорошо понимаю пустопорожнесть трепа про инвестора которому нужны точные суммы. Инвестору нужно чтобы руководитель проекта был грамотный и чтобы этот руководитель проекта сказал: «да сделаем, не ссы».
По поводу госконтрактов. Тут опять все просто. нужно всеголиш больше тратить лаве на девочек и мальчиков которые будут писать эти никому не нужные документа с календарными планами и прочей лабудой. С госзаказчиками на мой взгляд самая сложная работа это как раз переговорное сопровождение продажи. Нужно выявить кто реально принимает решение в этой огромной госмахине. И не одна бутылка коньякак будет выпита пока это будет сделана. Эта задача тоже решается итеративно. Нужно в самом начале проекта начать генерить документы требующие утверждения и следить за их движением. Внутри вашего госзаказчика. И тогда многие скрытые вещи станут явными.
По поводы правды жизни. Тут опять таки я не видел ни одного проекта которые был запланирован через PERT наприсован в диаграммме ганта и эта диаграмма дожила до конце проекта. Если мне такой проект покажут то было бы интересно посмотреть на менеджера. Я пожалуй сразу же ему предложу работу.
Я вижу решение этого вопроса так:
— Мы выделяем срок на одну итерацию. на первую итерацию можно выделить например 25% от всего времени.
— И за время итерации делаем весь проект целиком. Естесвтенно делаем его тяпляп. Но зато весь.
— Когда подходим ко второй итерации мы уже гораздо лучше понимаем где поднажать и где подзабить. И второй раз делаем уже более детально. После второй итерации у нас снова есть работающий продукт, с большим кол-вом рбшечек.
Для супер сложных и больших проектов время первой итерации может быть меньше в процентном отношении и быть где-то 5-10%. В маленьких проектах я думаю можно делать в две итерации, и выделать на первую итерацию 40%. Но что такое большой и что такое маленький это все от глазомера естественно зависит:)
Наша идея в том что если слишком много дедлайнов то можно запутаться. И потом еще тратить кучу времени на пересогласование дедлайнов.
Для себя я нашел ответ. Как это ни банально звучит, но нужно учится работать в команде. Нужно учится делится знаниями и быть готовым подхватить идеи других людей и принять их в свое сердце.
Каждая «унылая» работа в которой пробовал себя автор топика это был шанс создать что-то в команде. И почему-то про это не сказано ни слова. Почему все эти работы такие унылые? Может быть просто наш герой изначально не искал такую команду с которой будет готов разделить свои идеи, цели, надежды. Вероятно герой гнался за запрлатой или удобным расположением офиса или возможностью свободного графика. Но не искал в глазах босса и коллег отблеск того огня который зажигает звезды.
Как именно найти свою команду я не знаю. Я недавно читал историю Пиксара и мне очень понравилось что художник который в итоге привел компанию к коммерческому успеху в производтсве мультиков просто любил заглядывать к ребытам в офис и хотел немного помоч им с иллюстрациями.
Собственно в мире нет недостатка идей. Идей сейчас очень много и очень много действительно хороших. А вот недостаток команд ощущается очень остро.
На вскидку можно назвать так: «Договариваемся на берегу или как не потерять заказчика». Но это я вывод сделал за автора. Может ваша мысль она другая все-таки