Комментарии 33
Трудно оттащить руководство от календарей. Все хотят знать в первую очередь о сроках.
Что через месяц будет проект, сделанный на 100%, а желательно завтра.
Что через месяц будет проект, сделанный на 100%, а желательно завтра.
Руководство право в том что дедлайны нужны. Кто-то же будет пользоваться результатом.
Наша идея в том что если слишком много дедлайнов то можно запутаться. И потом еще тратить кучу времени на пересогласование дедлайнов.
Наша идея в том что если слишком много дедлайнов то можно запутаться. И потом еще тратить кучу времени на пересогласование дедлайнов.
Не просто руководство. Вся наша жизнь привязана ко времени.
Время линейно, а проект… так и хочется структурировать. Линейное и структурированное красиво скрестить, к сожалению невозможно. То что предлагает автор — эрзац. Красиво, но… сделать сплав прямого с ломаным не получится. Что то страдает, либо сроки размываются, либо структура плывет.
Время линейно, а проект… так и хочется структурировать. Линейное и структурированное красиво скрестить, к сожалению невозможно. То что предлагает автор — эрзац. Красиво, но… сделать сплав прямого с ломаным не получится. Что то страдает, либо сроки размываются, либо структура плывет.
В теории то что вы говорите верно.
На практике же требования проекте все время плывут. Я видел в своей жизни решение когда проектная команда все время обвиняет некое «руководство» и постоянное изменение требований. Вот типо из-за всего этого бардака я нас календарный план плывет.
Ну да круто отмазались. IT-отдел или кто-то там еще не виноват. А если нужно действительно сделать проект как можно быстрее так чтобы заработало на практике? В этом случае чем быстрее вы выкатите полный вижн архитектуры и демонстрацию того как все взаимодействует чем быстрее вы получите уточненные требования.
На практике же требования проекте все время плывут. Я видел в своей жизни решение когда проектная команда все время обвиняет некое «руководство» и постоянное изменение требований. Вот типо из-за всего этого бардака я нас календарный план плывет.
Ну да круто отмазались. IT-отдел или кто-то там еще не виноват. А если нужно действительно сделать проект как можно быстрее так чтобы заработало на практике? В этом случае чем быстрее вы выкатите полный вижн архитектуры и демонстрацию того как все взаимодействует чем быстрее вы получите уточненные требования.
Поддерживаю всеми руками итеративный процесс! Самому всегда нравилось развивать идею постепенно.
Но тут есть два но, знать когда еще рано останавливаться, и знать когда нужно остановиться! Потому что можно не доработать и оставить проект в запущенном состоянии, а можно усовершенствовать вечно, везде нужна своя мера.
Но тут есть два но, знать когда еще рано останавливаться, и знать когда нужно остановиться! Потому что можно не доработать и оставить проект в запущенном состоянии, а можно усовершенствовать вечно, везде нужна своя мера.
Да есть такая тема непоняткой где поднажать и где подзабить.
Я вижу решение этого вопроса так:
— Мы выделяем срок на одну итерацию. на первую итерацию можно выделить например 25% от всего времени.
— И за время итерации делаем весь проект целиком. Естесвтенно делаем его тяпляп. Но зато весь.
— Когда подходим ко второй итерации мы уже гораздо лучше понимаем где поднажать и где подзабить. И второй раз делаем уже более детально. После второй итерации у нас снова есть работающий продукт, с большим кол-вом рбшечек.
Для супер сложных и больших проектов время первой итерации может быть меньше в процентном отношении и быть где-то 5-10%. В маленьких проектах я думаю можно делать в две итерации, и выделать на первую итерацию 40%. Но что такое большой и что такое маленький это все от глазомера естественно зависит:)
Я вижу решение этого вопроса так:
— Мы выделяем срок на одну итерацию. на первую итерацию можно выделить например 25% от всего времени.
— И за время итерации делаем весь проект целиком. Естесвтенно делаем его тяпляп. Но зато весь.
— Когда подходим ко второй итерации мы уже гораздо лучше понимаем где поднажать и где подзабить. И второй раз делаем уже более детально. После второй итерации у нас снова есть работающий продукт, с большим кол-вом рбшечек.
Для супер сложных и больших проектов время первой итерации может быть меньше в процентном отношении и быть где-то 5-10%. В маленьких проектах я думаю можно делать в две итерации, и выделать на первую итерацию 40%. Но что такое большой и что такое маленький это все от глазомера естественно зависит:)
Ваш метод не совсем удобен. Объясню практикой.
Я руковожу разработкой букмекерской конторы, так же само решил сделать бету (весь проект но тяпляп, но весь), а потом посмотреть на ее работу, на фидбек игроков и усовершенствовать.
После беты пришлось почти все модули переписывать заново, что бы усовершенствовать.
Это заняло много времени. Разработчики «были готовы» к усовершенствованию, но не к тому, который понадобился.
Пришлось писать заново, а что еще хуже отказаться от некоторых…
Я руковожу разработкой букмекерской конторы, так же само решил сделать бету (весь проект но тяпляп, но весь), а потом посмотреть на ее работу, на фидбек игроков и усовершенствовать.
После беты пришлось почти все модули переписывать заново, что бы усовершенствовать.
Это заняло много времени. Разработчики «были готовы» к усовершенствованию, но не к тому, который понадобился.
Пришлось писать заново, а что еще хуже отказаться от некоторых…
Да интересная проблема.
Из вашего краткого описания объективный вывод сделать сложно. Я понял что в вашем случае бизнес-логика которая закладывалась изначально оказалась неверной. И после тестирования выяснилось что нужна совсем другая логика.
Если так то ваш пример это просто идеальная иллюстрация выгоды итеративного подхода. Если бы вы решили сразу все сделать то потратили гораздо больше ресурсов, но пришли бы все равно к тому же результату и все нужно было переделывать.
Насколько я понимаю вы еще не совсем удачно использовали итеративный подход. Вы заложили много гибкости надеясь на то что это будет для вас спасением. В результате же оказалось что ваши прогнозы не сбылись. Если бы вы изначально делали еще более тяпляпное решение без излишней гипкости то ввяснили пробблемы несоответствия бизнес-логики и архитектуры гораздо раньше.
Из вашего краткого описания объективный вывод сделать сложно. Я понял что в вашем случае бизнес-логика которая закладывалась изначально оказалась неверной. И после тестирования выяснилось что нужна совсем другая логика.
Если так то ваш пример это просто идеальная иллюстрация выгоды итеративного подхода. Если бы вы решили сразу все сделать то потратили гораздо больше ресурсов, но пришли бы все равно к тому же результату и все нужно было переделывать.
Насколько я понимаю вы еще не совсем удачно использовали итеративный подход. Вы заложили много гибкости надеясь на то что это будет для вас спасением. В результате же оказалось что ваши прогнозы не сбылись. Если бы вы изначально делали еще более тяпляпное решение без излишней гипкости то ввяснили пробблемы несоответствия бизнес-логики и архитектуры гораздо раньше.
Много глобальных слов поэтому поэтому кое что не понятно =)
Я говорил про усовершенствование, а не про изменения в корне первой логике.
Хорошо, вот пример:
В букмекерской конторе изначально планировался чат.
Требования, как и везде-обращение в чате, бан, ввод текста-все стандартно.
Но потом видя его в работе, решили усовершенствовать-добавить платные и бесплатные смайлы. И ве остальное оставить как есть, логику не менять. В итоге, чат не был предусмотрен на отображение графики, как в поле ввода, так и в общем окне, и еще с операциями счета игрока- тоже были проблемы. Пришлось переписывать.
Я говорил про усовершенствование, а не про изменения в корне первой логике.
Хорошо, вот пример:
В букмекерской конторе изначально планировался чат.
Требования, как и везде-обращение в чате, бан, ввод текста-все стандартно.
Но потом видя его в работе, решили усовершенствовать-добавить платные и бесплатные смайлы. И ве остальное оставить как есть, логику не менять. В итоге, чат не был предусмотрен на отображение графики, как в поле ввода, так и в общем окне, и еще с операциями счета игрока- тоже были проблемы. Пришлось переписывать.
Вроде понятна ситуация. Ну я опять не вижу проблему в итеративном подходе.
Вы же захотели смайлы много позже чем запустился чат в первоначальном виде.
И чем быстрее вы этот чат бы запустили тем быстрее бы пришло понимание того что и как нужно усовершенстовать. То есть если бы вы не запускали а сидели и продумывали всю широту функциональности то может быть до сих пор бы проектировали огромную махину.
Возможно вас расстраивает то что результата вашего труда нужно выбрасывать. Ну так да. Самое ценное это ведь не код, а вижн продукта или еще можно сказать ТЗ.
Вы же захотели смайлы много позже чем запустился чат в первоначальном виде.
И чем быстрее вы этот чат бы запустили тем быстрее бы пришло понимание того что и как нужно усовершенстовать. То есть если бы вы не запускали а сидели и продумывали всю широту функциональности то может быть до сих пор бы проектировали огромную махину.
Возможно вас расстраивает то что результата вашего труда нужно выбрасывать. Ну так да. Самое ценное это ведь не код, а вижн продукта или еще можно сказать ТЗ.
Да, здесь Вы правы! Чем раньше запустили бы чат, тем раньше поняли, что еще нужно.
Мне уже нравиться такой подход.) Но есть вопросы.
Мы выпускаем «тяпляп» чат, люди заходят-видят, что чат тяпляп-пишут «добавьте смайлы»(очень ценный feedback) уходят и запоминают, что у нас плохой чат. И потом, когда где то о нас услышат, сразу вспомнят наш «тяпляп чат» и будут негативно относиться? Как вы такое прокомментируете?
Мне уже нравиться такой подход.) Но есть вопросы.
Мы выпускаем «тяпляп» чат, люди заходят-видят, что чат тяпляп-пишут «добавьте смайлы»(очень ценный feedback) уходят и запоминают, что у нас плохой чат. И потом, когда где то о нас услышат, сразу вспомнят наш «тяпляп чат» и будут негативно относиться? Как вы такое прокомментируете?
Ну вообще говоря итеративных подход не подразумевает выкатку решения конечным пользователям. Это уже на усмотрение.
В вашем случае наверно стоит делать так. Вы делаете сайт и сами его активно тестируете. Ну или если очень хочется даете его потестировать небольшой группе пользователей. Это могут быть ваши сотрудники например, когда вариант с сотрудниками не прокатывает (например потому что азартных сотрудников нет) то можно давать сайт всем пользователям, но специально тратить на продвижение лиш чуть чуть. Этим управляя кол-вом пользователей на старте.
На сколько я помню идея системы инвайтов как раз и возникла у какой-то конторы которя тестила свой сервис. И не хотела чтобы куча людей поняла что он стремный.
Тут вообще есть тысячи вариантов достижения цели. А цель простая — собрать решение целиком и посмотреть в целом как это работает и не упущены ли какие нибудь требования.
По сути итеративных помогает избежать:
1. Проблемы того что интеграция модулей проекта может оказаться неожиданно сложной
2. Проблема того что реальные бизнес требования могут сильно отличатся от прогнозируемых
В вашем случае наверно стоит делать так. Вы делаете сайт и сами его активно тестируете. Ну или если очень хочется даете его потестировать небольшой группе пользователей. Это могут быть ваши сотрудники например, когда вариант с сотрудниками не прокатывает (например потому что азартных сотрудников нет) то можно давать сайт всем пользователям, но специально тратить на продвижение лиш чуть чуть. Этим управляя кол-вом пользователей на старте.
На сколько я помню идея системы инвайтов как раз и возникла у какой-то конторы которя тестила свой сервис. И не хотела чтобы куча людей поняла что он стремный.
Тут вообще есть тысячи вариантов достижения цели. А цель простая — собрать решение целиком и посмотреть в целом как это работает и не упущены ли какие нибудь требования.
По сути итеративных помогает избежать:
1. Проблемы того что интеграция модулей проекта может оказаться неожиданно сложной
2. Проблема того что реальные бизнес требования могут сильно отличатся от прогнозируемых
Да, кстати-хорошая идея с инвайтами. А вот с тестами у меня плохо получилось. Я не хотел показывать плохо работающее приложение и никому не показывал. А когда показал-все за голову схватились((. Больше так поступать не буду. Это много и нервов и дополнительные временные и финансовые потери.
Последнее ваши предложения не понял. Понятно, что нужно собрать, как можно больше информации от будущих пользователей при этом как можно меншьим показывать проект. Здесь помогут друзья, коллеги, инвайты, определенные небольшие группы людей.
Последнее ваши предложения не понял. Понятно, что нужно собрать, как можно больше информации от будущих пользователей при этом как можно меншьим показывать проект. Здесь помогут друзья, коллеги, инвайты, определенные небольшие группы людей.
Ну круто. Приятно что кому-то пригодились мои идеи.
По поводу последних предложений.
1. Интеграция модулей. Рекомендую вам прочитать книжку Фредерика Брукса «Мифический человеко-месяц». Можно до серидины только читать. Там он хорошо объясняет что бывает если интеграцию модулей оставлять на конец.
2. Неопределенность бизнес-требований. Тут я не знаю наглядный пример который поможет объяснить. Я подумаю еще. Можное привести полярные примеры.
. фундаментальное научное исследование — принципиально не известно что поучиться на выходе
. прикладное исследование, инженерное проектирование — есть общее представление, но многое станет понятно в процессе.
. Южный полюс — сборка из готового инструментария по жесткому ТЗ. Таким например бывает типовое строительство по утвержденному чертежу.
Во многих сверах современного бизнеса все больше задач по созданию систем. Такие задачм лучше требуют других рабочих и другие моделей управения этими рабочими.
Я говорю о так называемых Knowledge Workers, уже 50 лет про них говорят, но только недавно они действительно стали влиять на рынок и на модели бизнеса.
Нужно статью будет еще допиливать эту.
По поводу последних предложений.
1. Интеграция модулей. Рекомендую вам прочитать книжку Фредерика Брукса «Мифический человеко-месяц». Можно до серидины только читать. Там он хорошо объясняет что бывает если интеграцию модулей оставлять на конец.
2. Неопределенность бизнес-требований. Тут я не знаю наглядный пример который поможет объяснить. Я подумаю еще. Можное привести полярные примеры.
. фундаментальное научное исследование — принципиально не известно что поучиться на выходе
. прикладное исследование, инженерное проектирование — есть общее представление, но многое станет понятно в процессе.
. Южный полюс — сборка из готового инструментария по жесткому ТЗ. Таким например бывает типовое строительство по утвержденному чертежу.
Во многих сверах современного бизнеса все больше задач по созданию систем. Такие задачм лучше требуют других рабочих и другие моделей управения этими рабочими.
Я говорю о так называемых Knowledge Workers, уже 50 лет про них говорят, но только недавно они действительно стали влиять на рынок и на модели бизнеса.
Нужно статью будет еще допиливать эту.
Да и еще у Брукса есть важная тема: «Проблема второго проекта». Обязательно просмотрите. Очень класно.
Нужно еще добавить что мы тоже 10 лет уже как занимаемся разработкой ПО для букмейкерских контор.
И в нашем первом проекте заказчик не смог сформуровать требования к системе. В итоге мы открыли свою букмейкерку, проанализировали бизнес-процессы и сами написали себе ТЗ. Дальше все случилось как надо:)
И вот на этом примере мы поняли что такое итеративных подход на практике. Сейчас мы дополнили свое понимание объектным подходом
И в нашем первом проекте заказчик не смог сформуровать требования к системе. В итоге мы открыли свою букмейкерку, проанализировали бизнес-процессы и сами написали себе ТЗ. Дальше все случилось как надо:)
И вот на этом примере мы поняли что такое итеративных подход на практике. Сейчас мы дополнили свое понимание объектным подходом
Этот метод известен как метод прототипирования. И, в подавляющем большинстве случаев требует того, чтобы после сбора требований прототип был выброшен и программа писалась заново (описывалось у Макконнелла в Rapid Development и, наверняка, ещё в куче мест). Как показала практика, если кода тяп-ляп достаточно много, то его дорого рефакторить. Дешевле переписать. И это надо закладывать в план.
Кстати, есть и ещё одна проблема. Руководство/заказчик, увидев прототип, радосно потирая ручки говорит: «Ну вот почти всё готово». И им замумукаешься доказывать, что это всего четверть работы и до конца ещё далеко.
Кстати, есть и ещё одна проблема. Руководство/заказчик, увидев прототип, радосно потирая ручки говорит: «Ну вот почти всё готово». И им замумукаешься доказывать, что это всего четверть работы и до конца ещё далеко.
Тематика демократизации и итеративности действительно очень популярна и многими молодыми, но малоопытными управленцами, воспринимается как единственно возможное решение. Во многих случаях это то, что приносит ощутимо лучший результат, и часто ее использование, правда, является лучшим выходом. Есть еще некогда модная фраза «When it's done»: мы не знаем заранее срока, но знаем, что полученный на выходе продукт будет отличного качества (примеры из мира игр: GTA, Max Payne, игры Blizzard и Valve).
Но все это напоминает иллюзии, сравнимые с верой в Санта-Клауса.
Чтобы ты мог себе позволить такой принцип, нужно иметь на это ресурсы. Если от окупаемости проекта зависит твоя судьба, то тут особо не понавыращиваешься с неясными концами проекта. Такой проект имеет право на жизнь, только если он — твое хобби или является побочным — как тот кустик слева от большого дерева на иллюстрации в статье. Эксперимент, так сказать. Есть, конечно, еще вариант с доверчивыми инвесторами, но это еще менее вероятнее.
Задумайтесь: что, если ты привлекаешь инвестиции? Что, если у тебя кредит? Банки и инвесторы в большинстве своем хотят увидеть деньги, и они не будут расписывать план выплат в модели «When you'll pay», сроки будут установлены самые что ни на есть конкретные. И твои deadline в проекте также становятся конкретными, и надо делать все и сразу, потому что иначе твой продукт не будут использовать, а значит — ты не сможешь его продавать, а значит — не сможешь платить по счетам.
Увы, правда жизни суровее.
И все бизнесы так жили и живут. Почитайте, как развивался Starbucks, например :)
Напоследок напомню, что у нас в стране очень большой оборот производится на госзаказах. А там проекты такие, что срыв сроков — это уголовная ответственность. Как бы Вы рекомендовали действовать в такой ситуации?..
Но все это напоминает иллюзии, сравнимые с верой в Санта-Клауса.
Чтобы ты мог себе позволить такой принцип, нужно иметь на это ресурсы. Если от окупаемости проекта зависит твоя судьба, то тут особо не понавыращиваешься с неясными концами проекта. Такой проект имеет право на жизнь, только если он — твое хобби или является побочным — как тот кустик слева от большого дерева на иллюстрации в статье. Эксперимент, так сказать. Есть, конечно, еще вариант с доверчивыми инвесторами, но это еще менее вероятнее.
Задумайтесь: что, если ты привлекаешь инвестиции? Что, если у тебя кредит? Банки и инвесторы в большинстве своем хотят увидеть деньги, и они не будут расписывать план выплат в модели «When you'll pay», сроки будут установлены самые что ни на есть конкретные. И твои deadline в проекте также становятся конкретными, и надо делать все и сразу, потому что иначе твой продукт не будут использовать, а значит — ты не сможешь его продавать, а значит — не сможешь платить по счетам.
Увы, правда жизни суровее.
И все бизнесы так жили и живут. Почитайте, как развивался Starbucks, например :)
Напоследок напомню, что у нас в стране очень большой оборот производится на госзаказах. А там проекты такие, что срыв сроков — это уголовная ответственность. Как бы Вы рекомендовали действовать в такой ситуации?..
Я читал как развивался старбакс. Не вижу там противоречий.
По поводу сроков проекта. Никто не говорит что они не нужна. Срок очень даже нужен. Но планирование всего проекта нужно делать не от PERT и WBS, а от архитектуры. Что это дает? Это дает то что уже после первой итерации есть хорошее понимание всех рисков проекта. И соответвенно ключевые ресырсы направляются именно на самые рисковые точки. В результате имеем сильное преимущество перед календарным планированием проекта.
По поводу инвестиций. Конечно если ты береш деньги у государственых фондов которым нужно прикрывать жопу бумажками тебе нужно делать всякие расчеты NPV, IRR и прочее. Но любой грамотный инвестор хорошо понимает что все эти расчеты разбиваются о то что невозмодно грамотно запланировать выручку. Ну за исключением того когда у тебя есть уже известный заказчик и подписан контракт. Но тогда это уже вообще халава. И таже девочка экономист легко справится с расчетами. да именно та же которая для госконтрактов рыбы календарных планов заполняет. У меня есть опыт организации процесса инвестиционного анализа в открывании типовых столовок с известными параметрами контракта и размером дотации. И я очень хорошо понимаю пустопорожнесть трепа про инвестора которому нужны точные суммы. Инвестору нужно чтобы руководитель проекта был грамотный и чтобы этот руководитель проекта сказал: «да сделаем, не ссы».
По поводу госконтрактов. Тут опять все просто. нужно всеголиш больше тратить лаве на девочек и мальчиков которые будут писать эти никому не нужные документа с календарными планами и прочей лабудой. С госзаказчиками на мой взгляд самая сложная работа это как раз переговорное сопровождение продажи. Нужно выявить кто реально принимает решение в этой огромной госмахине. И не одна бутылка коньякак будет выпита пока это будет сделана. Эта задача тоже решается итеративно. Нужно в самом начале проекта начать генерить документы требующие утверждения и следить за их движением. Внутри вашего госзаказчика. И тогда многие скрытые вещи станут явными.
По поводы правды жизни. Тут опять таки я не видел ни одного проекта которые был запланирован через PERT наприсован в диаграммме ганта и эта диаграмма дожила до конце проекта. Если мне такой проект покажут то было бы интересно посмотреть на менеджера. Я пожалуй сразу же ему предложу работу.
По поводу сроков проекта. Никто не говорит что они не нужна. Срок очень даже нужен. Но планирование всего проекта нужно делать не от PERT и WBS, а от архитектуры. Что это дает? Это дает то что уже после первой итерации есть хорошее понимание всех рисков проекта. И соответвенно ключевые ресырсы направляются именно на самые рисковые точки. В результате имеем сильное преимущество перед календарным планированием проекта.
По поводу инвестиций. Конечно если ты береш деньги у государственых фондов которым нужно прикрывать жопу бумажками тебе нужно делать всякие расчеты NPV, IRR и прочее. Но любой грамотный инвестор хорошо понимает что все эти расчеты разбиваются о то что невозмодно грамотно запланировать выручку. Ну за исключением того когда у тебя есть уже известный заказчик и подписан контракт. Но тогда это уже вообще халава. И таже девочка экономист легко справится с расчетами. да именно та же которая для госконтрактов рыбы календарных планов заполняет. У меня есть опыт организации процесса инвестиционного анализа в открывании типовых столовок с известными параметрами контракта и размером дотации. И я очень хорошо понимаю пустопорожнесть трепа про инвестора которому нужны точные суммы. Инвестору нужно чтобы руководитель проекта был грамотный и чтобы этот руководитель проекта сказал: «да сделаем, не ссы».
По поводу госконтрактов. Тут опять все просто. нужно всеголиш больше тратить лаве на девочек и мальчиков которые будут писать эти никому не нужные документа с календарными планами и прочей лабудой. С госзаказчиками на мой взгляд самая сложная работа это как раз переговорное сопровождение продажи. Нужно выявить кто реально принимает решение в этой огромной госмахине. И не одна бутылка коньякак будет выпита пока это будет сделана. Эта задача тоже решается итеративно. Нужно в самом начале проекта начать генерить документы требующие утверждения и следить за их движением. Внутри вашего госзаказчика. И тогда многие скрытые вещи станут явными.
По поводы правды жизни. Тут опять таки я не видел ни одного проекта которые был запланирован через PERT наприсован в диаграммме ганта и эта диаграмма дожила до конце проекта. Если мне такой проект покажут то было бы интересно посмотреть на менеджера. Я пожалуй сразу же ему предложу работу.
Но планирование всего проекта нужно делать не от PERT и WBS, а от архитектуры.
Если честно, не вижу большого отличия.
С точки зрения подхода вы изобрели Product breakdown structure (PBS) — элемент Product-based planning в Prince2. А с точки зрения инструмента PBS так же легко создаётся и управляется в том же MS Project, как и WBS. Принципиальной какой-то разницы между WBS и PBS нет и там и там речь идёт о декомпозиции целого на части. Впрочем планирование от продукта мне самому чуть более удобно.
Если честно, не вижу большого отличия.
С точки зрения подхода вы изобрели Product breakdown structure (PBS) — элемент Product-based planning в Prince2. А с точки зрения инструмента PBS так же легко создаётся и управляется в том же MS Project, как и WBS. Принципиальной какой-то разницы между WBS и PBS нет и там и там речь идёт о декомпозиции целого на части. Впрочем планирование от продукта мне самому чуть более удобно.
Спасибо за проект, очень рад, что кто-то развивает Google Wave в стороны командной работы. Попробовал зарегистрироваться у вас на сайте (Проект Волна) не получается, хотя почта гугловская…
Вас не затруднит подробно рассказать, что происходит при попытке регистрации?
Еще Google Wave закрыла регистрацию для пользователей с google акаунтомами которые не @gmail.com
Странность в том, что на Wave я уже зарегистрирован, почта на гугле тоже есть, у вас на сайте на этой странице: projectvolna.com/ru/accounts/login/gmail_required/
Для использования сервисов Project Volna необходимо добавить службу GMail в ваш Google аккаунт:
www.google.com/accounts/NewAccount?service=mail.
Затем пройдите по ссылке для продолжения регистрации
Нажимаю на пройдите по ссылке для продолжения регистрации и ничего не происходит, остаюсь на той же странице на вашем сайте…
Для использования сервисов Project Volna необходимо добавить службу GMail в ваш Google аккаунт:
www.google.com/accounts/NewAccount?service=mail.
Затем пройдите по ссылке для продолжения регистрации
Нажимаю на пройдите по ссылке для продолжения регистрации и ничего не происходит, остаюсь на той же странице на вашем сайте…
«календарный план уходит в прошлое»?
по нашему опыту, большинство клиентов интересуют сроки в первую очередь, ну и конечно, чтобы поменьше людей привлекалось — вседь это влияет на стоимость заказа. В таких случаях без хорошей разбивки (breakdown) и календарного плана с учетом зависимостей никуда. Как еще объяснишь заказчику, почему так долго или так дорого?
«Проект, в котором от начала до конца жил календарный план» — в коммерческих проектах он никогда не был и не будет одим и тем же. Он должен жить вместе с проектом. И возможно это только если делать достаточно детальный WBS (почему бы не основывать его на архитектуре), и связывать работы зависимостями.
Кстати, у заказчика не всегда есть понимание того, что для него первостепенно важно, а что — нет, но намного чаще есть какие-то временные ограничения.
Обсуждение календарного плана (и его поправок на изменения внешней среды) с заказчиком, покажут достаточно быстро, какие функции системы критичны для него а какие — могут подождать.
по нашему опыту, большинство клиентов интересуют сроки в первую очередь, ну и конечно, чтобы поменьше людей привлекалось — вседь это влияет на стоимость заказа. В таких случаях без хорошей разбивки (breakdown) и календарного плана с учетом зависимостей никуда. Как еще объяснишь заказчику, почему так долго или так дорого?
«Проект, в котором от начала до конца жил календарный план» — в коммерческих проектах он никогда не был и не будет одим и тем же. Он должен жить вместе с проектом. И возможно это только если делать достаточно детальный WBS (почему бы не основывать его на архитектуре), и связывать работы зависимостями.
Кстати, у заказчика не всегда есть понимание того, что для него первостепенно важно, а что — нет, но намного чаще есть какие-то временные ограничения.
Обсуждение календарного плана (и его поправок на изменения внешней среды) с заказчиком, покажут достаточно быстро, какие функции системы критичны для него а какие — могут подождать.
В вашем посте мне видится подмена задачи. В статью речь идёт о выполнении проекта с точки зрения команды проекта. А работа с заказчиком (в том числе и с ценой заказа) и организация выполнения проекта — это всё же разные вещи. Можно, конечно, показывать заказчику тот план, по которому вы фактически работаете, но так бывает не очень часто. Заказчику обычно нужна не столь подробная разбивка на задачи, другая терминология описания задач и т.д. и т.п. Ну и торговлю за цену заказа никто не отменял.
Впрочем, возможно, что мы обсуждаем разный масштаб заказов. Мне чаще приходилось иметь дело с проектами, объем которых измеряется в человекогодах. Если речь идёт о работах за пару штук баксов, то описанную мною мутотень никто, конечно, разводить не будет. :)
Впрочем, возможно, что мы обсуждаем разный масштаб заказов. Мне чаще приходилось иметь дело с проектами, объем которых измеряется в человекогодах. Если речь идёт о работах за пару штук баксов, то описанную мною мутотень никто, конечно, разводить не будет. :)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Объектно-ориентированный подход к управлению проектами