В своей статье Pete Deemer, chief product officer (India Research and Development) of Yahoo! и Gabrielle Benefield, senior director (Agile Development) of Yahoo! рассказывают о разнице между традиционной "водопадной" методологией разработки и Scrum, разновидностью agile-методологий. В конце приведены некоторые итоги применения скрама в яху — за 2 последних года 75 проектов компании и почти 700 человек были переведены на работу по данной методике.
Здравствуйте, rsn81, Вы писали:
R>Здравствуйте, Курилка, Вы писали:
R>И, о чем тема?
Дак прочитай статью, не очень она большая... Так в общем думаю, людям разбирающимся, кто уже знаком более-менее со скрамом, будет не сильно интересно, но иллюстративнмы будут результаты, их смотри в предпоследнем абзаце, можно искать по значку процентов
Здравствуйте, Курилка, Вы писали:
К>Дак прочитай статью, не очень она большая... Так в общем думаю, людям разбирающимся, кто уже знаком более-менее со скрамом, будет не сильно интересно, но иллюстративнмы будут результаты, их смотри в предпоследнем абзаце, можно искать по значку процентов
Да прочитал я, правда, по диагонали, % видел.
Просто только что обнаружил, что дал ссылку не на ту статью с "Открытых систем" (читал ее с бумаги), вот оригинал: Двигатель программной революции — там Джеф Сазерленд (собственно автор Scrum) хвастается теми же цифрами, поминает как бы походя Yahoo, Google, Microsoft. Дык это... сам себя не похвалишь — никто и не вспомнит.
Здравствуйте, rsn81, Вы писали:
R>Просто только что обнаружил, что дал ссылку не на ту статью с "Открытых систем" (читал ее с бумаги), вот оригинал: Двигатель программной революции — там Джеф Сазерленд (собственно автор Scrum) хвастается теми же цифрами, поминает как бы походя Yahoo, Google, Microsoft. Дык это... сам себя не похвалишь — никто и не вспомнит.
Про автора — вопрос спорный, обычно вроде Швабера за такового считают, хотя были до них ещё всякие Штали, Такеучи и иже с ними
Здравствуйте, Курилка, Вы писали:
К>В своей статье Pete Deemer, chief product officer (India Research and Development) of Yahoo! и Gabrielle Benefield, senior director (Agile Development) of Yahoo! рассказывают о разнице между традиционной "водопадной" методологией разработки и Scrum, разновидностью agile-методологий. В конце приведены некоторые итоги применения скрама в яху — за 2 последних года 75 проектов компании и почти 700 человек были переведены на работу по данной методике.
Угу, обычное дело, все сравнивают все это с мистическим ватерфолом. Раньше я как-то это обычно воспринимал, как все, начиная трепетать при страшном слове ватерфол. Однако, сейчас ловлю себя на том, что на самом деле я не понимаю что такое ватерфол и ни разу за свою жизнь не видел его в работе. Я всегда верил книгам, которые про него, великий и ужасный пишут как про ад кромешный.
Первое. Пардон, who the fuckin guy waterfall is? Что это за процесс такой — на него есть стандарт? Или он существует только на страницах учебников в массовом воображении? Может быть, этим словом все кому не лень называют неорганизованную на местах разработку, когда документы пишут потому, что инструкция заставляет, и никто из команды не проходил никаких процессных тренингов?
Все пишут про великий и ужасный ватерфол, но на практике те же древние ГОСТы (где еще искать ватерфол, как не там? мне пришлось по работе ознакомится с профилными ГОСТами — отличные штуки оказались) регламентируют этапы разработкис критериями выходов, жестко не регламентируя активность на них. Ну прям как RUP, один в один. Все что задает ГОСТ — определяет этапы работ, которые должны быть оплачены, и по результатам которых проходит приемка работ (разумеется, без приемки оплату проводить нельзя). Там нет никакого ватерфола. Не заметно разрекламированных страшных ватерфольных свойств и у PSP/TSP, по которому я работал, и который если смотреть по книжным канонам — ну полный ватерфол должен быть.
Короче — когда пишут "по сравнению с ватерфол" я честно не понимаю с чем сравнивают. Сомневаюсь, что сами авторы ответов и статей это понимают. Скорее всего — с той фигней, которая выполняла у них роль процесса разработки до скрамов, а уж тут, извините, кто во что горазд. Но назвать как-то надо? Вот, видимо, и называют.
Второе. Экспертные оценки "лучше" "хуже" "много" "мало" "сложно" "просто"- в топку. Эти ответы ничего не стоят. Это банальный опрос населения с нечетко поставленным вопросом, который все понимают по разному, и усредненный ответ на который лишен смысла. Дать достоверный ответ на вопросы "как возросла ваша продуктивность" и прочие связанные вопросы можно только анализируя метрики, которых, я так понимаю, эти организации не вели до внедения скрама (не факт, что ведут после), и потому реально ничего сравнить не могут.
Здравствуйте, Gaperton, Вы писали:
G>Все пишут про великий и ужасный ватерфол, но на практике те же древние ГОСТы (где еще искать ватерфол, как не там? мне пришлось по работе ознакомится с профилными ГОСТами — отличные штуки оказались) регламентируют этапы разработкис критериями выходов, жестко не регламентируя активность на них. Ну прям как RUP, один в один. Все что задает ГОСТ — определяет этапы работ, которые должны быть оплачены, и по результатам которых проходит приемка работ (разумеется, без приемки оплату проводить нельзя). Там нет никакого ватерфола. Не заметно разрекламированных страшных ватерфольных свойств и у PSP/TSP, по которому я работал, и который если смотреть по книжным канонам — ну полный ватерфол должен быть.
Слушай, а нет где в публичном доступе этих самых ГОСТов?
Здравствуйте, Gaperton, Вы писали:
G>Все пишут про великий и ужасный ватерфол, но на практике те же древние ГОСТы (где еще искать ватерфол, как не там? мне пришлось по работе ознакомится с профилными ГОСТами — отличные штуки оказались) регламентируют этапы разработкис критериями выходов, жестко не регламентируя активность на них. Ну прям как RUP, один в один. Все что задает ГОСТ — определяет этапы работ, которые должны быть оплачены, и по результатам которых проходит приемка работ (разумеется, без приемки оплату проводить нельзя). Там нет никакого ватерфола. Не заметно разрекламированных страшных ватерфольных свойств и у PSP/TSP, по которому я работал, и который если смотреть по книжным канонам — ну полный ватерфол должен быть.
Угу, если вспомнить, что на западе про ГОСТы никто и не слышал...
G>Короче — когда пишут "по сравнению с ватерфол" я честно не понимаю с чем сравнивают. Сомневаюсь, что сами авторы ответов и статей это понимают. Скорее всего — с той фигней, которая выполняла у них роль процесса разработки до скрамов, а уж тут, извините, кто во что горазд. Но назвать как-то надо? Вот, видимо, и называют.
Хочется согласиться с этим... но что-то мешает.
Здравствуйте, Gaperton, Вы писали:
G>Второе. Экспертные оценки "лучше" "хуже" "много" "мало" "сложно" "просто"- в топку. Эти ответы ничего не стоят. Это банальный опрос населения с нечетко поставленным вопросом, который все понимают по разному, и усредненный ответ на который лишен смысла. Дать достоверный ответ на вопросы "как возросла ваша продуктивность" и прочие связанные вопросы можно только анализируя метрики, которых, я так понимаю, эти организации не вели до внедения скрама (не факт, что ведут после), и потому реально ничего сравнить не могут.
В дополнение можно сказать, что переход на новый процесс разработки, как правило, дает временный прирост продуктивности (почему-то возрастает мотивация инженеров). Это усложняет оценку эффективности нового процесса.
Здравствуйте, Курилка, Вы писали:
К>Здравствуйте, Gaperton, Вы писали:
G>>Все пишут про великий и ужасный ватерфол, но на практике те же древние ГОСТы (где еще искать ватерфол, как не там? мне пришлось по работе ознакомится с профилными ГОСТами — отличные штуки оказались) регламентируют этапы разработкис критериями выходов, жестко не регламентируя активность на них. Ну прям как RUP, один в один. Все что задает ГОСТ — определяет этапы работ, которые должны быть оплачены, и по результатам которых проходит приемка работ (разумеется, без приемки оплату проводить нельзя). Там нет никакого ватерфола. Не заметно разрекламированных страшных ватерфольных свойств и у PSP/TSP, по которому я работал, и который если смотреть по книжным канонам — ну полный ватерфол должен быть.
К>Слушай, а нет где в публичном доступе этих самых ГОСТов?
Вроде как нет, доступ к ГОСТам вообще говоря платный. Мы недавно запросили госты по стандартам DVB (цифровое телевидение), так за это надо платить, если мне память не изменяет, 40 тыщ рублей. ГОСТ на разработку микролектроники лежит у коллеги на столе, остальные надо запрашивать в специальном отделе. То, что есть в наличии — они выдают только в печатном виде. Можно попробовать в сети поискать.
Здравствуйте, rsn81, Вы писали:
R>Здравствуйте, Gaperton, Вы писали:
G>>Все пишут про великий и ужасный ватерфол, но на практике те же древние ГОСТы (где еще искать ватерфол, как не там? мне пришлось по работе ознакомится с профилными ГОСТами — отличные штуки оказались) регламентируют этапы разработкис критериями выходов, жестко не регламентируя активность на них. Ну прям как RUP, один в один. Все что задает ГОСТ — определяет этапы работ, которые должны быть оплачены, и по результатам которых проходит приемка работ (разумеется, без приемки оплату проводить нельзя). Там нет никакого ватерфола. Не заметно разрекламированных страшных ватерфольных свойств и у PSP/TSP, по которому я работал, и который если смотреть по книжным канонам — ну полный ватерфол должен быть. R>Угу, если вспомнить, что на западе про ГОСТы никто и не слышал...
ГОСТ Р ИСО 9000:2001 — это, по твоему, что? Это официальный перевод ISO 9000, про который на западе многие слышали. И таких ГОСТов много. Вообще — слышали, не слышали — это не имеет значения, на самом деле. Слабо мне верится, что наши ГОСТы писались без оглядки на западный опыт, и что наши ГОСТы сильно продвинутее западных подходов. Скорее, наоборот.
G>>Короче — когда пишут "по сравнению с ватерфол" я честно не понимаю с чем сравнивают. Сомневаюсь, что сами авторы ответов и статей это понимают. Скорее всего — с той фигней, которая выполняла у них роль процесса разработки до скрамов, а уж тут, извините, кто во что горазд. Но назвать как-то надо? Вот, видимо, и называют. R>Хочется согласиться с этим... но что-то мешает.
Ну, так в этом и вопрос. Расскажи признаки ватерфола. Мне известен из книг только один существенный — фаза четко приписана к виду активности, типа код писать во время дизайна запрещено, а если ошибка будет обнаружена в дизайне на фазе кодирования — надо откатываться на предыдущую фазу (дизайна). Вообще — это бред, никакого "откатывания" на практике не делают. Фаза, которая началась, продолжается до своего окончания. И разумеется, ошибки дизайна совершенно спокойно правят во время кодирования. По другому нельзя — к такому циклическому процессу просто невозможно выписать план. И никто откатывать двадцать пять раз фазу назад при обнаружении проблем в дизайне не будет — это очевидный бред. Может, я не те книги читал? Дайте ссылку на нормальные.
Здравствуйте, the_dip, Вы писали:
_>Здравствуйте, Gaperton, Вы писали:
G>>Второе. Экспертные оценки "лучше" "хуже" "много" "мало" "сложно" "просто"- в топку. Эти ответы ничего не стоят. Это банальный опрос населения с нечетко поставленным вопросом, который все понимают по разному, и усредненный ответ на который лишен смысла. Дать достоверный ответ на вопросы "как возросла ваша продуктивность" и прочие связанные вопросы можно только анализируя метрики, которых, я так понимаю, эти организации не вели до внедения скрама (не факт, что ведут после), и потому реально ничего сравнить не могут.
_>В дополнение можно сказать, что переход на новый процесс разработки, как правило, дает временный прирост продуктивности (почему-то возрастает мотивация инженеров). Это усложняет оценку эффективности нового процесса.
Нам консультанты, внедрявшие PSP/TSP говорили другое. Они утверждали, что в первый год внедрения новых процессов разработки после неорганизованной разработки продуктивность падает. Пока инженеры не привыкнут. Не знаю, насколько это касается скрама, но насчет PSP/TSP они правы — раньше чем через полгода точно просветление не наступает.
Мне кажется, тут основной момент не в разработчиках, а в менеджменте. Внедрение методологии играет для них роль ликбеза — их в принудительном порядке учат технологическому процессу и указывают их место в этом процессе. А менеджеры, в отличии от разработчиков, в большей степени некомпетентны, до такой степени, что зачастую могут свести на ноль или минус работу большого количества людей. С этой точки зрения — действительно неважно, какой процесс, польза по любому будет .
Здравствуйте, Gaperton, Вы писали:
G>Ну, так в этом и вопрос. Расскажи признаки ватерфола. Мне известен из книг только один существенный — фаза четко приписана к виду активности, типа код писать во время дизайна запрещено, а если ошибка будет обнаружена в дизайне на фазе кодирования — надо откатываться на предыдущую фазу (дизайна). Вообще — это бред, никакого "откатывания" на практике не делают. Фаза, которая началась, продолжается до своего окончания. И разумеется, ошибки дизайна совершенно спокойно правят во время кодирования. По другому нельзя — к такому циклическому процессу просто невозможно выписать план. И никто откатывать двадцать пять раз фазу назад при обнаружении проблем в дизайне не будет — это очевидный бред. Может, я не те книги читал? Дайте ссылку на нормальные.
Ну так, может, потому и книг нет, что бред? И никто не говорит, что практикует waterfall, просто потому, что не модно и не солидно сейчас это говорить. Хотя люди, которые искренне верят в то, что можно все продумать заранее, есть. И практикуют они итерационный процесс с каждой итерацией по пол-года, где первые два месяца идет исключительно анализ требований для итерации, вторые два месяца — дизайн, последние — кодирование и тестирование. И планы на итерацию составляют. Почему невозможно? Очень даже возможно, ведь "откатов" быть не должно, если все хорошо продумать заранее. А кто не может продумать, у того руки кривые.
G>Слабо мне верится, что наши ГОСТы писались без оглядки на западный опыт, и что наши ГОСТы сильно продвинутее западных подходов.
Тем не менее часто это именно так. Просто по той причине, что наши ГОСТы основываются на ISO и зарубежных военных стандартах (в последнее время всё больше), а на наши ГОСТы смотрит только бывшая зона влияния СССР.
D>И никто не говорит, что практикует waterfall, просто потому, что не модно и не солидно сейчас это говорить.
Не говорят. Говорят:
— После согласования требований формируем окончательный бюджет, начинаем разработку, после окончания разработки тестируем и принимаем продукт по согласованным требованиям.
Здравствуйте, A.Lokotkov, Вы писали:
AL>Здравствуйте, Курилка, Вы писали:
К>>Слушай, а нет где в публичном доступе этих самых ГОСТов?
AL>кое-что
Это круто, но это на самом деле маленько не то — то ЕСКД (единая система конструкторской документации) и ЕСПД (программной документации).
А по процессам разработки надо немного другое — "порядок выполнения опытно-конструкторских работ". У меня есть военный ГОСТ РВ 15.203-2001 со штампом и в печатном виде. Цитирую:
Этот стандарт устанавливает:
группы ОКР
этапы ОКР
требования к выполнению ОКР
порядок выполнения и приемки этапов ОКР
функции основных участков ОКР и их взаимоотношения
Однако, цель данного стандарта состоит в том, чтобы регламентировать отношения заказчика и исполнителя по военному государственному заказу, а также упорядочить ход самих работ. Это накладывает определенный отпечаток . Там очень тяжеловесный документооборот, и рассчитано это на очень объемные проекты, например — разработка комплекса ПВО, вместе с ракетами, ПО, вычислительной машиной, и всей-превсей лабудой. Хотя, в принципе, все по делу — явно бредовых вещей в стандарте не обнаружено.
Здравствуйте, VGn, Вы писали:
G>>Слабо мне верится, что наши ГОСТы писались без оглядки на западный опыт, и что наши ГОСТы сильно продвинутее западных подходов.
VGn>Тем не менее часто это именно так. Просто по той причине, что наши ГОСТы основываются на ISO и зарубежных военных стандартах (в последнее время всё больше), а на наши ГОСТы смотрит только бывшая зона влияния СССР.
Не понял. Уточни, что именно так по твоему?
1) госты писались без оглядки на западный опыт.
2) Наши госты сильно продвинутее западных подходов.
Здравствуйте, Gaperton, Вы писали:
G>Это круто, но это на самом деле маленько не то — то ЕСКД (единая система конструкторской документации) и ЕСПД (программной документации). G>А по процессам разработки надо немного другое — "порядок выполнения опытно-конструкторских работ". У меня есть военный ГОСТ РВ 15.203-2001 со штампом и в печатном виде.
По приведенной ссылке надо смотреть надо ЕСС АСУ. В частности по стадиям -- ГОСТ 34.601-90. Гражданские фирмы, занимающиеся автоматизированными системами, обычно следуют этим стандартам.
Здравствуйте, VGn, Вы писали:
D>>И никто не говорит, что практикует waterfall, просто потому, что не модно и не солидно сейчас это говорить.
VGn>Не говорят. Говорят: VGn>- После согласования требований формируем окончательный бюджет, начинаем разработку, после окончания разработки тестируем и принимаем продукт по согласованным требованиям.
Я так понял по вашей переписке, что я убежденный последователь waterfall, и горжусь этим
А что, можно разрабатывать продукты по другому? Если это именно продукт, который будет продаваться, то тогда не дай вам бог требования от маркетинга прощелкать, и не протестировать на соответствие. У вас в случае разработки собственного продукта по собственным требованиям есть все возможности по грамотному управлению требованиями и для предварительного проектирования. Не воспользоваться этими возможностями — это разгильдяйство, а применение в том случае методик, отрицающих предварительное проектирование — оправдание разгильдяйства.
Если же это заказная разработка, и требования не ясны, то можно посмотреть, как такая проблема решается при госзаказе. А решается она очень просто — сначала открывают НИР с целью уточнения требований, результат которого — аналитика (какие эксперименты и прототипы вам надо написать, и сможете ли вы ими воспользоваться в дальнейших ОКР — неважно) или НИОКР для практической проверки реализуемости (часть результата — опытные образцы, т.е. прототипы). НИР, как вы понимаете, не подчиняется циклу waterfall, для НИР это не важно — там не надо трассировать требования и обеспечивать тестирование, как в ОКР. Есть, короче, разница между штучным опытным концепт-каром и серийной машиной.
Это проекты разных типов, они принципиально по разному планируются и контроллируются, естественно их надо разделять. К примеру, для исследований сложно прогнозировать продолжительность — нет никаких методов, поэтому надо вести работу итеративно и сделать в управлении акцент на целеполагание, заранее назначив фиксированную дату завершения. Чтобы что успели к этой дате, то и сдали. Но цель НИР — это не разработка программы или продукта. Цель — выяснить новые знания, снять неопределенность. Поэтому, мощно контроллировать качество прототипов на этапе НИР — выброшенные деньги. Так же как и писать полнофункицоналные прототипы.
Здравствуйте, A.Lokotkov, Вы писали:
AL>Здравствуйте, Gaperton, Вы писали:
G>>Это круто, но это на самом деле маленько не то — то ЕСКД (единая система конструкторской документации) и ЕСПД (программной документации). G>>А по процессам разработки надо немного другое — "порядок выполнения опытно-конструкторских работ". У меня есть военный ГОСТ РВ 15.203-2001 со штампом и в печатном виде.
AL>По приведенной ссылке надо смотреть надо ЕСС АСУ. В частности по стадиям -- ГОСТ 34.601-90. Гражданские фирмы, занимающиеся автоматизированными системами, обычно следуют этим стандартам.
Круто. Ты бы дал какой-нибудь глоссарий по этим стандартам — чтобы проще орентироваться было.
Здравствуйте, Gaperton, Вы писали:
G>Здравствуйте, A.Lokotkov, Вы писали:
AL>>Здравствуйте, Gaperton, Вы писали:
G>>>Это круто, но это на самом деле маленько не то — то ЕСКД (единая система конструкторской документации) и ЕСПД (программной документации). G>>>А по процессам разработки надо немного другое — "порядок выполнения опытно-конструкторских работ". У меня есть военный ГОСТ РВ 15.203-2001 со штампом и в печатном виде.
AL>>По приведенной ссылке надо смотреть надо ЕСС АСУ. В частности по стадиям -- ГОСТ 34.601-90. Гражданские фирмы, занимающиеся автоматизированными системами, обычно следуют этим стандартам.
Допускается исключить стадию "Эскизный проект" и отдельные этапы работ на всех стадиях, объединять стадии "Технический проект" и "Рабочая документация" в одну стадию "Технорабочий проект". В зависимости от специфики создаваемых АС и условий их создания допускается выполнять отдельные этапы работ до завершения предшествующих стадий, параллельное во времени выполнение этапов работ, включение новых этапов работ.
Ай-ай. Ай да ватерфор . Надо-ж — допускается выполнять отдельные этапы работ до заверения предшествующих стадий . Это ж РУП какой-то получается .
Короче говоря. Под ватерфолом общественностью понимается наличие предварительного проектирования, плюс ранняя работа нед требованиями. Т.е., как в RUP:
1) Определяемся, что мы делаем.
2) Решаем, как мы делаем.
3) Делаем первую полнофункциональную версию, доступную тестерам
4) Доводим ее до рабочего состояния.
Вопрос — чем цикл разработки RUP отличается от waterfall? Ну не тем же, что при waterfall "на фазе дизайна кодировать запрещено" — как мы выясняем, очень даже можно. Просто это в результаты этапа дизайна не войдет, как и в RUP.
Здравствуйте, Gaperton, Вы писали:
G>Ай-ай. Ай да ватерфор . Надо-ж — допускается выполнять отдельные этапы работ до заверения предшествующих стадий . Это ж РУП какой-то получается .
Глоссарий по ЕСПД. Стадии разработки -- по ГОСТ 19.102-77.
Waterfall -- это жупел, которым пугают детей... вернее, потенциальных пользователей новомодных agile-течений, никогда не работавших в "стандартном" процессе. Как видно из наших ГОСТ-ов и стандартов IEEE серии Software Engineering, которые, насколько я могу судить, и считаются воплощением водопадного процесса, они изначально предполагали и предполагают итеративность разработки, когда в конце каждой итерации появляется все более близкая к цели модель того, что хотелось сделать в начале. Проблема, я думаю, в том, что зачастую при следовании стандартам конечная цель проектирования подменяется некачественными артефактами промежуточных стадий и этапов (обычно тонны никчемной бумаги, которую кроме непосредственных авторов никто не читал). Это в первую очередь относится к большим инновационным проектам и к ситуациям, когда на стадии предварительного дизайна предпринимаются попытки построить всю систему на бумаге. С другой стороны, суровая правда жизни заключается в том, что пресловутый "ватерфол" применительно к сложным проектам (сложность размера и сложность кол-ва взаимосвязей) все-таки позволяет достичь результата. При условии, что в процессе имеются люди, которым не требуется задавать вопрос в интернете "А нет ли у кого образца ТЗ (SRS), ПЗ (SDD) ..?".
Здравствуйте, A.Lokotkov, Вы писали:
G>>Ай-ай. Ай да ватерфор . Надо-ж — допускается выполнять отдельные этапы работ до заверения предшествующих стадий . Это ж РУП какой-то получается .
AL>Глоссарий по ЕСПД. Стадии разработки -- по ГОСТ 19.102-77. AL>Waterfall -- это жупел, которым пугают детей... вернее, потенциальных пользователей новомодных agile-течений, никогда не работавших в "стандартном" процессе. Как видно из наших ГОСТ-ов и стандартов IEEE серии Software Engineering, которые, насколько я могу судить, и считаются воплощением водопадного процесса, они изначально предполагали и предполагают итеративность разработки, когда в конце каждой итерации появляется все более близкая к цели модель того, что хотелось сделать в начале.
Хорошо, что мне не одному это кажется . Я уж почти начал думать, что я с ума сошел, или всю жизнь тупой был .
AL>Проблема, я думаю, в том, что зачастую при следовании стандартам конечная цель проектирования подменяется некачественными артефактами промежуточных стадий и этапов (обычно тонны никчемной бумаги, которую кроме непосредственных авторов никто не читал). Это в первую очередь относится к большим инновационным проектам и к ситуациям, когда на стадии предварительного дизайна предпринимаются попытки построить всю систему на бумаге.
Эта проблема известна — "сдвиг акцента с разработки продукта на разработку документации". Еще демарко в пиплваре про нее писал. Ну, и многие, я думаю, наблюдали это на практике.
...
В том то и дело, что ОКР в разработке ПО отличается от обычной ОКР, тем что Вы заранее не знаете полных требований. Именно для выяснения этих требований, а также основанной на ней архитектуры и нужна итеративная разработка.
Да. Можно сначала провести кропотливую работу по выяснению, подтверждению и обоснованию требований, а потом основываясь на них начать разработку (водопад).
Но во первых, это не так эффективно, как эволюция прототипов. И больше сроки. И больше бумаги.
Во вторых, я ещё не видел проектов, где бы не было ошибок в требованиях.
В третьих, заказчик часто изменяет свои требования, имея уже частично работающий продукт (не всё можно оценить на прототипах). Особенно, когда связь между потребителем и разработчиком слишком длинна.
В четвёртых, тестирование во время разработки позволяет уменьшить общую пиковую нагрузку тестировщиков и повысить их эффективность (если это конечно не обезьянки с клавиатурами). Это касается также итеративной работы архитекторов, аналитиков и самих разработчиков.
В пятых, это уже проверено Хотя не скажу, что всё так просто. Как я уже убедился, нормальный итеративный процесс разработки требует более высокой квалификации абсолютно всех участников. Кому-то это минус
При всём при этом я допускаю, что в некоторых проектах водопад может быть применен (требования бывают разные).
Врядли в той же космической промышленности заказчик не знает, что ему надо.
Хотя и тут применяют скорее не водопад, а циклическую разработку, которая не эффективней итеративной, потому что увеличивает объём работы при том же качестве.
Заодно кину камень в огород XP, которое мне представляется не более чем играми в песочнице.
Здравствуйте, VGn, Вы писали:
VGn>... VGn>В том то и дело, что ОКР в разработке ПО отличается от обычной ОКР, тем что Вы заранее не знаете полных требований. Именно для выяснения этих требований, а также основанной на ней архитектуры и нужна итеративная разработка.
Есть два вида разработки ПО — разработка (коробочного) продукта, и разработка на заказ под нужды внешнего заказчика.
При первом виде разработки требования составляете вы, и никто другой. У вас есть все возможности выяснить требования. При втором виде разработки целесообразно провести анализ требований, заслав к заказчику аналитика. Я выполнял эту работу — при анализе бизнес-процессов на сбор информации тратится примерно 2 часа на одного исполнителя. Кроме этого, вам нужна информация об оргструктуре предприятия и заполненные реальными данными печатные формы всех документов. После чего, в течении дня-двух (примерно 20% времени от сбора данных — у нас были короткие заказы) тратится на построение модели бизнес-процессов организации и грубое предварительное проектирование — разбивку на модули.
Здесь ситуация простая — либо вы умеете собирать требования, либо нет. Если да — вам дешевле их собрать и проанализировать, иначе итерациям конца и края не будет, и ваш заказчик рискует вылететь за бюджет на автоматизацию так и не получив нужный ему результат. В этом случае вы не просто потеряете заказчика, но еще и получите негативный отзыв.
Насчет итеративной разработки — ее никто не мешает применять при так называемом "водопаде" (которого на практике не существует, но об этом позже) — вы бьете всю функицональность на модули и делаете по одному модулю с законченной функциональностью за итерацию. Это простой здравый смысл — чем чаще вы получаете деньги, тем меньше ваши финансовые риски. Для заказчика также психологически проще проводить приемку законченными работающими модулями.
VGn>Да. Можно сначала провести кропотливую работу по выяснению, подтверждению и обоснованию требований, а потом основываясь на них начать разработку (водопад).
Вам никто не мешает во время сбора требований делать прототипы системы и показывать их клиенту. "Водопад" это не запрещает. Вы можете начинать активности по разработке до завершения предыдущих стадий, если это необходимо.
VGn>Но во первых, это не так эффективно, как эволюция прототипов. И больше сроки. И больше бумаги.
Это как раз более эффективно, чем эволюция прототипов, и сроки меньше. Потому, что переделывать меньше надо. А если вы требования на бумаге не зафиксируете, и акты приемки подписывать не будете, то вас на котракте fixed cost клиенты разведут как лоха, залезете в минус, и еще с ним поругаетесь. На бумаге надо фиксировать бизнес-процессы (в виде сценариев/use case — обязательно) и архитектуру — так дешевле. Без бумаги вы в них элементарно запутаетесь, и разработчики ошибок наляпают из-за разного понимания бизнес-процессов. Более того, непонятно как вы тесты собрались разрабатывать без описания сценариев на бумаге. Из головы их будете брать? Вот и пойдут у вас проблемы на приемке, как тут не так давно описывал человек, который правильно работает по scrum. Потому что требованиями надо управлять, и выполнять их трассировку, чтобы не иметь проблем на приемке.
Что до описания архитектуры — то для бизнес-приложений при готовых сценариев, описании ролей, и наличии заполненных форм документов и отчетов (собирается при анализе) это совершенно тривиальная задача — там практически нечего проектировать, все предельно быстро и просто. Не выполнять предварительного проектирования в этом случае — глупо, оно слишком простое.
VGn>Во вторых, я ещё не видел проектов, где бы не было ошибок в требованиях.
В моих проектах не было крупных ошибок в требованиях (приводящих к коррекции архитектуры и дизайна) начиная примерно с 2000 года — только косметика и мелочь. После того, как я несколько раз крупно лажанулся с требованиями, и сделал выводы. Требования надо уметь собирать, чтобы в них ошибок не было, это умение, которому надо учиться. Можно, конечно, вместо тренировки в анализе требований, плюнуть и применять agile. Это несколько снизит вред от отсутствия управления требованиями, но проблемы останутся. И серьезные проблемы — сыграют очень больно и неожиданно.
Кроме этого — при анализе требований я могу во многих случаях позволить себе брать с клиента fixed cost, и дать ему подробную раскладку за что он конкретно платит — это для него более понятный и психологически выгодный контракт,чем оплата непонятной "работы" с "итерациями". В моем случае он платит за результат, который нагляден и понятен. Это я к тому, что при прочих равных я выиграю тендер у вас.
VGn>В третьих, заказчик часто изменяет свои требования, имея уже частично работающий продукт (не всё можно оценить на прототипах). Особенно, когда связь между потребителем и разработчиком слишком длинна.
Для этого проводят анализ бизнес-процессов — чтобы собрать реальную информацию о фактических бизнес-процессах (от исполнителей, а не со слов менеджмента, нихрена в том ни пендрящем). Имея точный анализ, вы никогда не столкнетесь с пожеланием, радикально расходящимся с вашей картиной — это просто невозможно. Для этого согласут и подписывают ТЗ, изменения к которому идут за отдельную плату. Для этого клиенту в тяжелых случаях на раннем этапе показывают прототипы гуя (хотя при задачах автоматизации при наличии проведенного анализа это делать скорее вредно, чем полезно). Для этого планируют этап "внедрение", на котором выполняются доработки по ходу эксплуатации.
VGn>В четвёртых, тестирование во время разработки позволяет уменьшить общую пиковую нагрузку тестировщиков и повысить их эффективность (если это конечно не обезьянки с клавиатурами). Это касается также итеративной работы архитекторов, аналитиков и самих разработчиков.
Тестирование во время разработки не есть изобретение agile. Прекрасно и давным давно применяется при т.н. "водопаде". Тестирование вообще-то необходимо чтобы задачу разработчику закрыть, а задачи желательно делать короткими — не более недели. Так делается в самом водопадном из водопадов — PSP/TSP.
VGn>В пятых, это уже проверено Хотя не скажу, что всё так просто. Как я уже убедился, нормальный итеративный процесс разработки требует более высокой квалификации абсолютно всех участников. Кому-то это минус
Конечно минус. У меня высокая квалификация, которая позволяет писать навернутые штуки на сложном С++. Однако, я ценю свое время, и предпочту Erlang, который позволяет мне тратить свое время более продуктивно, не думая о целой куче всякой ерунды. Так же и с процессом — я не понимаю, зачем нужен процесс разработки, требующий высокой квалификации (т.е. постоянного напряжения от инженеров для достижения адекватного результата). Это означает, что он не помогает работать, а мешает. Хороший процесс должен упрощать жизнь, снимая проблемы коммуникации, позволяя людям заниматься существенными вещами, трятя свой креатив на инженерную работу.
VGn>При всём при этом я допускаю, что в некоторых проектах водопад может быть применен (требования бывают разные). VGn>Врядли в той же космической промышленности заказчик не знает, что ему надо. VGn>Хотя и тут применяют скорее не водопад, а циклическую разработку, которая не эффективней итеративной, потому что увеличивает объём работы при том же качестве.
Все проще. Никакого waterfall-а, которым пугают людей, в природе несуществует. Сейчас сами поймете, если вдумчиво ответите на вопрос. Чем водопад отличается от RUP? Вот фазы RUP — упрощенно, по книге Murray Cantor "Project management with UML", которая лежит на столе.
1) Определяемся, что мы делаем.
2) Решаем, как мы делаем.
3) Делаем первую полнофункциональную версию, доступную тестерам
4) Доводим ее до рабочего состояния.
Вопрос — в чем отличие от ватерфол? Подумайте как следует, применима ли ваша критика к RUP? Подумайте, понимаете ли вы на самом деле разницу между RUP и этим, как его, ватерфол? Правильный ответ вас удивит — "да, ваша критика относится и к RUP тоже в полном объеме" — так как вы считаете критерием ватерфола наличие предварительной работы с требованиями и предварительного дизайна. Вот они, в критериях завершения двух первых фаз в цикле разработки RUP. Вы, очевидно, этого не хотели, потому, что RUP — "это хорошо", а ватерфол, "это плохо и страшно". Попробуйте обяснить этот казус — как так вышло, что вы жостко аргументируете в том числе и против RUP, который считаете хорошим. Я намеренно не стал приводить идиотские названия фаз RUP, которые выдуманы с целью показать, что тут якобы что-то новое есть. Нихрена нового нет в их цикле разработки на самом деле, кроме несколько более общей чем в классике формулировки критериев завершения фаз (за что им спасибо).
Ларман указывает на то, что Ройс описывал итеративный процесс, но его не поняли и упростили его модель до однопроходной. И в таком виде она попала в DOD-STD-2167, откуда разнеслась по всему миру.
It is no small irony that 2167 was then used as input to other standards, both within the United States and internationally. For example, the British JSP-188, German V-Model (also the basis of the Austrian and Swiss standards), and the French GAM-T-17 were influenced by 2167, with an emphasis on single-pass waterfall phases, and early large, signed-off specifications before construction.
Вообще если посмотреть на любые подходы, то можно выделить их ограниченность
Какой ожидается результат от разработки По?
Для вотерфольных моделей, и многих итерационных цели две: 1) создать программу 2) написать документацию
Получается вместо одного продукта делается ДВА!
В гибких методологиях, особенно SCRUM та же ерунда. Только пункт второй вычёркивается и добавляется ещё один 1) создать программу
2) (ВЫЧЕРКНУТЬ) написать документацию 3) создать самоорганизующуюся Команду
То есть тоже 2 продукта! Фактически. когда заказчик взращивает команду -- он для себя создаёт новый продукт. А Agile всего лишь помогает ему это делать.
Понятно. Первая статья про организованную разработку, судя по тексту. Это не методология. Это простое замечание, что иногда разработчики проектируют перед тем как кодировать, и то в принципе хорошо. Но иногда они ошибаются, и тогда опять проектируют. Это научно-популярная статья про то, как работает програмист. Никакая это не модель жизненного цикла. Просто симпатичная статья, для своего времени так вообще блеск.
F> wikipedia: Waterfall model F> C.Larman, Agile and Iterative Development: A Manager's Guide. (Topic: The Historical Accident of Waterfall Validity?)
F>Ларман указывает на то, что Ройс описывал итеративный процесс, но его не поняли и упростили его модель до однопроходной.
Разумеется он описал итеративный процесс. У него в там циклически чередуются каждые две соседних активности.
И в таком виде она попала в DOD-STD-2167, откуда разнеслась по всему миру.
Ага. Ранний американский военный стандат. Видимо тоже, первый.
F>
F>It is no small irony that 2167 was then used as input to other standards, both within the United States and internationally. For example, the British JSP-188, German V-Model (also the basis of the Austrian and Swiss standards), and the French GAM-T-17 were influenced by 2167, with an emphasis on single-pass waterfall phases, and early large, signed-off specifications before construction.
Ну теперь понятно, один в нормальный человек в первый раз более-менее формально описал процесс разработки, и тысяча долбоящеров-менеджеров нихрена не разобравшись подхватили это как попугаи и начали повторять (что характерно, никто по большому счету по этому стандату DOD не работал, потому что работать по нему невозможно). Потом этот bullshit с названием waterfall попал в авторитетные толстые книги, и теперь уже инженеры, видя этот страшный "жупел" в авторитетных толстых книгах, пугаются, и внимают очередным пропагандистам "новых, совсем не таких как старых" методологий.
Остается посочуствовать автору "ватерфола". Его же теперь автором этого угребища из толстых книг считают почем зря.
Здравствуйте, denis miller, Вы писали:
DM>Вообще если посмотреть на любые подходы, то можно выделить их ограниченность
DM>Какой ожидается результат от разработки По?
От разработки ПО ожидается (сюрприз) ПО, работающее именно так, как требуется, причем не просто так, а сделанное именно за те деньги и к тому сроку, которые планировались. Как вы это сделаете — по большому счету неважно. У вас то либо получается, какой бы подхо вы не применяли, либо нет.
DM>Вот так всё просто
DM>>Какой ожидается результат от разработки По? G>От разработки ПО ожидается (сюрприз) ПО, работающее именно так, как требуется, причем не просто так, а сделанное именно за те деньги и к тому сроку, которые планировались. Как вы это сделаете — по большому счету неважно. У вас то либо получается, какой бы подхо вы не применяли, либо нет. DM>>Вот так всё просто G>Ага .
Ну стандартное предположение — а если требования меняются?
Здравствуйте, denis miller, Вы писали:
DM>>>Какой ожидается результат от разработки По? G>>От разработки ПО ожидается (сюрприз) ПО, работающее именно так, как требуется, причем не просто так, а сделанное именно за те деньги и к тому сроку, которые планировались. Как вы это сделаете — по большому счету неважно. У вас то либо получается, какой бы подхо вы не применяли, либо нет. DM>>>Вот так всё просто G>>Ага .
DM>Ну стандартное предположение — а если требования меняются?
Слово "меняются" предполагает, что они как-то меняются сами по себе. Это слово предполагает, что вы над требованиями невластны. Но на самом деле они не "меняются" сами — их всегда кто-то меняет. Обыкновенно, их меняет тот, кто их составляет. И на самом деле, требованиями вы можете и должны управлять. Если они меняются сами, и живут собственной жизнью — это означает, что вы ими никак не управляете, и вам надо обратить на это внимание, и принять корректирующие мероприятия для ликвидации крня проблемы.
Если кто-то изменил требования слишком сильно и слишком поздно — вы вылетаете за бюджет и ваш проект становится убыточен, никакой процесс разработки вам не поможет. Не сделаете вы электронную таблицу из текстового процессора — никакие методы рефакторинга не помогут. Если вы разрабатываете собственный продукт, вы сами источник требований и у вас они сами меняются — у вас великолепные шансы угробить вашу компанию. Применение разных agile в данном случае не лечит причину, это неэффективное симптоматическое лечение. Которое может на деле привести к усугублению проблемы.
Gaperton,
G>Угу, обычное дело, все сравнивают все это с мистическим ватерфолом. Раньше я как-то это обычно воспринимал, как все, начиная трепетать при страшном слове ватерфол. Однако, сейчас ловлю себя на том, что на самом деле я не понимаю что такое ватерфол и ни разу за свою жизнь не видел его в работе. Я всегда верил книгам, которые про него, великий и ужасный пишут как про ад кромешный.
DM>>Ну стандартное предположение — а если требования меняются? G>Если кто-то изменил требования слишком сильно и слишком поздно — вы вылетаете за бюджет и ваш проект становится убыточен,
А что мешает быть ближе к заказчику? На пьянки ходить вместе, жить жизнью заказчика...
Не только программировать их бизнес, но знать и быть в их бизнесе?
Здравствуйте, denis miller, Вы писали:
DM>Вообще если посмотреть на любые подходы, то можно выделить их ограниченность
DM>Какой ожидается результат от разработки По?
DM>Для вотерфольных моделей, и многих итерационных цели две: DM>1) создать программу DM>2) написать документацию DM>Получается вместо одного продукта делается ДВА!
О боже. Как Вы собираетесь поддерживать проект, не имея документации? Или у SCRUM-мастеров так принято — наследил и убежал, а после меня хоть трава не расти?
DM>В гибких методологиях, особенно SCRUM та же ерунда. Только пункт второй вычёркивается и добавляется ещё один DM>1) создать программу DM>2) (ВЫЧЕРКНУТЬ) написать документацию DM>3) создать самоорганизующуюся Команду
Товарищ, я Вас не вполне понимаю. Вы предлагаете на каждый проект заново команду создавать?
Здравствуйте, Gaperton, Вы писали:
G>Вопрос — в чем отличие от ватерфол? Подумайте как следует, применима ли ваша критика к RUP? Подумайте, понимаете ли вы на самом деле разницу между RUP и этим, как его, ватерфол? Правильный ответ вас удивит — "да, ваша критика относится и к RUP тоже в полном объеме" — так как вы считаете критерием ватерфола наличие предварительной работы с требованиями и предварительного дизайна. Вот они, в критериях завершения двух первых фаз в цикле разработки RUP. Вы, очевидно, этого не хотели, потому, что RUP — "это хорошо", а ватерфол, "это плохо и страшно". Попробуйте обяснить этот казус — как так вышло, что вы жостко аргументируете в том числе и против RUP, который считаете хорошим.
In the previous section we stated that the best process for a project is the smallest process that project could afford.
<...>
We discussed a minimal implementation of RUP which we called dX . The principles and practices of dX were identified several years ago by Ward Cunningham, Kent Beck, Ron Jeffries, and a host of other developers and methodologists. They have used this process on several projects with significant success. Because of that success, they have gathered quite a following. They call the process Extreme Programming; or for short: XP .
Здравствуйте, denis miller, Вы писали:
DM>>>Ну стандартное предположение — а если требования меняются? G>>Если кто-то изменил требования слишком сильно и слишком поздно — вы вылетаете за бюджет и ваш проект становится убыточен,
DM>А что мешает быть ближе к заказчику? На пьянки ходить вместе, жить жизнью заказчика...
Вот, как говорится, что бы ни делать, лишь бы не работать.
1. Ходить на пьянки с заказчиком не лучший способ управления требованиями.
2. "Близость к заказчику" тоже вам ничего не гарантирует. "Наши студенты становятся ближе к знаниям — ведь здание общежития находится всего в 50 метраж от университетской библиотеки".
3. У заказчика своя жизнь, у вас своя. Я предпочитаю жить своей жизнью, и управлять требованиями.
DM>Не только программировать их бизнес, но знать и быть в их бизнесе?
Знание и понимание их бизнеса — слишком широко берете. Вам заказчики платят не за это. Они платят вам за то, что вы делаете ровно то, что им нужно — даже если они сами не могут это сформулировать, а не за совместные пьянки, и на за разговоры по душам. Более того, они были бы благодарны вам за то, что вы не заставляете их это формулировать. Именно поэтому вам и платят — потому что у заказчика в частности нет специалистов по составлению ТЗ и анализу требований.
Здравствуйте, Павел Кузнецов, Вы писали:
G>>Вопрос — в чем отличие от ватерфол? Подумайте как следует, применима ли ваша критика к RUP? Подумайте, понимаете ли вы на самом деле разницу между RUP и этим, как его, ватерфол? Правильный ответ вас удивит — "да, ваша критика относится и к RUP тоже в полном объеме" — так как вы считаете критерием ватерфола наличие предварительной работы с требованиями и предварительного дизайна. Вот они, в критериях завершения двух первых фаз в цикле разработки RUP. Вы, очевидно, этого не хотели, потому, что RUP — "это хорошо", а ватерфол, "это плохо и страшно". Попробуйте обяснить этот казус — как так вышло, что вы жостко аргументируете в том числе и против RUP, который считаете хорошим.
ПК>
ПК>In the previous section we stated that the best process for a project is the smallest process that project could afford.
ПК><...>
В этом с ними не согласен. Многие проекты можно довести до конца вообще не следуя никаким процессам, и даже уложиться в бюджеты. И многие именно так и работают. И ничего. И что это означает? Процесс — это не есть неотвратимое зло, которое надо минимизировать (их исходная посылка — однобокий взгляд на вещи, типичный девелоперский — разработчиков прошу не обижаться, ведь процессы разработки решают в основном не ваши проблемы, на самом деле), процесс направлен на достижение вполне конкретных целей, которые диктуются бизнесом, и к слову, могут отличаться от одной организации к другой.
Цели эти должны рассматриваться с точки зрения проектного управления, в контексте задач, стоящих перед организацией. И цели эти очень просты — как оптимальным образом организовать групповую работу, чтобы достичь нужного результата (именно требуемого, других достигать не надо!) с требуемым качеством (именно с требуемым — не меньше не больше) в условиях ограниченного бюджета и сроков.
Что они там пишут? We stated that the best process for a project is the smallest process that project could afford?
Лучший процесс для проекта такой, который позволет не просто достичь поставленных целей, о которых у них вообще ни слова, но сделать это оптимальным способом. Т.е. дешевле и эффективнее. И не только локальных целей (сдать проект любой ценой), но и долговременных стратегических, затрагивая весь жизненный цикл продукта, и не только одного продукта здесь и сейчас — а в контексте общей продуктовой стратегии компании. Я, собственно, говорю о трассировке требований, вопросах поддержки и развития интеллектуальной собственности, а также аспектах ее повторного использования, планирования, и управлении приориетами.
ПК>We discussed a minimal implementation of RUP which we called dX . The principles and practices of dX were identified several years ago by Ward Cunningham, Kent Beck, Ron Jeffries, and a host of other developers and methodologists. They have used this process on several projects with significant success. Because of that success, they have gathered quite a following. They call the process Extreme Programming; or for short: XP .
Давно слышал что хр типа укоцанный РУП, и поэтому это очень круто. Видите-ли в чем тут фокус — на самом деле этот тезис ничего не означает. Жизненный цикл, на котором основан РУП — это general problem solving process. Вы любую активность на него натянуть можете без проблем, вообще. Включая процесс заваривания чая и хождения покакать. Цикл РУП — это не искуственные правила, а закон природы, который нарушить нельзя — у вас любой процесс решения пробем является "частным случаем РУП."
D>Ну так, может, потому и книг нет, что бред? И никто не говорит, что практикует waterfall, просто потому, что не модно и не солидно сейчас это говорить.
У нас водопад. Полет нормальный. Проекты сдаются успешно и во время.
Здравствуйте, prVovik, Вы писали:
V>Здравствуйте, dshe, Вы писали:
D>>Ну так, может, потому и книг нет, что бред? И никто не говорит, что практикует waterfall, просто потому, что не модно и не солидно сейчас это говорить.
V>У нас водопад. Полет нормальный. Проекты сдаются успешно и во время.
ПК>>In the previous section we stated that the best process for a project is the smallest process that project could afford.
G>Процесс — это не есть неотвратимое зло, которое надо минимизировать <...> процесс направлен на достижение вполне конкретных целей <...>
Все зависит от того, что понимать под "the smallest process that project could afford". Как я понимаю, это как раз и значит, "smallest process", при котором заданные цели достигаются. В этом случае, таки да, "больший" процесс является злом, т.к. приводит к большим издержкам.
It may be necessary to produce something other than software in order to eventually produce the software that is our goal. It may also be necessary to produce some artifact that acts to support the software that is our goal. However, such intermediate artifacts are not the goal of the process. They are, at best, a means to an end. They also represent a cost. A good process will decrease the demand for such intermediate artifacts to the barest possible minimum.
Собственно, минимизация издержек -- и есть самая суть agile, при определенной трактовке, разделяемой не всеми. (При этой трактовке) в этом они очень родственны с lean product development / lean manufacturing, родившимися из TPS (Toyota Production System).
G>Лучший процесс для проекта такой, который позволет не просто достичь поставленных целей, о которых у них вообще ни слова, но сделать это оптимальным способом. Т.е. дешевле и эффективнее.
Ага, мне кажется, об этом и идет речь.
The goal of a software process is the production of software. Software that works, software that is on time, software that is within budget, software that can be maintained, software that can be reused. If this goal is met while preserving the rights of the developers and customers, then the process is a success.
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
DM>>А что мешает быть ближе к заказчику? На пьянки ходить вместе, жить жизнью заказчика... G>Вот, как говорится, что бы ни делать, лишь бы не работать. G>1. Ходить на пьянки с заказчиком не лучший способ управления требованиями. G>2. "Близость к заказчику" тоже вам ничего не гарантирует. "Наши студенты становятся ближе к знаниям — ведь здание общежития находится всего в 50 метраж от университетской библиотеки". G>3. У заказчика своя жизнь, у вас своя. Я предпочитаю жить своей жизнью, и управлять требованиями.
Пример не очень подходит. Отвечу просто — а может у них цели разные?
DM>>Не только программировать их бизнес, но знать и быть в их бизнесе? G>Знание и понимание их бизнеса — слишком широко берете. Вам заказчики платят не за это. Они платят вам за то, что вы делаете ровно то, что им нужно — даже если они сами не могут это сформулировать, а не за совместные пьянки, и на за разговоры по душам. Более того, они были бы благодарны вам за то, что вы не заставляете их это формулировать. Именно поэтому вам и платят — потому что у заказчика в частности нет специалистов по составлению ТЗ и анализу требований.
Вот поэтому получается то, что получается.
Уверяю — заказчик не быдла, он хочет успеха. Только вопрос — хотите ли его вы?
Мне вот не понятен одно, а зачем ТЗ ? (не путить с визион-документом в 2-3 странички, а подробное, верифицированное, ревьюированное и всякие бузззвордс слова).
D>>Ну так, может, потому и книг нет, что бред? И никто не говорит, что практикует waterfall, просто потому, что не модно и не солидно сейчас это говорить. V>У нас водопад. Полет нормальный. Проекты сдаются успешно и во время.
Дык, так у нас тоже водопад
Ты давай детали выкладывай
Здравствуйте, Gaperton, Вы писали:
G>Здравствуйте, prVovik, Вы писали:
V>>Здравствуйте, dshe, Вы писали:
D>>>Ну так, может, потому и книг нет, что бред? И никто не говорит, что практикует waterfall, просто потому, что не модно и не солидно сейчас это говорить.
V>>У нас водопад. Полет нормальный. Проекты сдаются успешно и во время.
G>Можешь описать свой процесс разработки?
Процесс очень формальный, с кучей участников, activity и документов. Весь описывать не буду (я все и сам не знаю ), напишу только в очень общих чертах.
Приходит человек из бизнеса, приносит в IT BRD (business requirements document). В этом документе он пишет свои идеи, мысли и т.д.
В девелоперской команде сидит бизнес-аналитик. Он изучает этот BRD и много общается с бизнесом, пытаясь понять, что у него на уме, какие проблемы и т.д.
Потом аналитик пишет SRS. SRS согласовывается с бизнесом и разработчиками. Программисты подключаются к проекту на этапе согласования SRS и могут инициировать изменение SRSa в соответствии с технической целесообразностью. Проходят множество митингов с участием представителей бизнеса, бинес-аналитика, девелопмент лидеров, программистов и, возможно, архитектора (если проект крупный и затрагивает много работающих систем). Весь этот базар заканчивается принятием и утверждением SRS. Замечу, что потом SRS в принцепе меняться может на любом этапе (хотя это сильно не приветствуется и означает, что на соответствующей фазе что-то профакали).
Затем программисты начинают программировать в ворде и писать TDS — technical design specification. Выглядт это так, как будто они пишут программу, но в качестве языка программирования используется обычный человеческий язык. На выходе получаем документ, в котором на нужном уровне детализации описано что и как будет сделано по проекту. В процессе этой деятельности дополнительно уточняется SRS. На основе TDS составляется project plan.
Итак, имеем три основных проектных документа:
1. BRD — что хотел заказчик.
2. SRS — как желаения заказчика были интерпретированы.
3. TDS — как надо реализовать интерпретацию желаний заказчика.
Любому новому человеку, подключающемуся к проекту дают именно три этих документа, прочитав которые он "врубается" в проект.
Далее начинается фаза разработки и программисты начинают писать код. Тут формальностей минимум и в разных командах эта фаза проходит по-разному. Выход из этой фазы опеределен конкретной датой явно и заранее.
Потом начинается SIT — system integration test, где к проекту подключаются тестеры. На данном этапе помимо тестирования, обкатывается стандартный процесс деплоймента проекта, пишется документация по деплойменту и саппорту.
Затем UAT — users acceptable test, где с системой играется заказчик.
В конце-концов проект выкатывается на продакшен и начинается фаза стабилизации.
Никто не утверждает, что описанный мной процесс является идеальным и подходит на все случаи жизни. Но для тех проектов, которые мы выполняем и в тех условиях, с теми заказчиками — он работает очень хорошо. Хотя, изначально я был настроен весьма скептически, так как читал много книг-ужасов про водопад
Здравствуйте, denis miller, Вы писали:
DM>Мне вот не понятен одно, а зачем ТЗ ?
ТЗ нужен программистам, чтобы они знали, что должны сделать.
ТЗ нужен заказчику, чтобы он заранее знал, что получит в конце разработки.
ТЗ нужен для того, чтобы сторонний человек мог разобраться в деталях функционирования готового проекта.
DM>>Мне вот не понятен одно, а зачем ТЗ ? V>ТЗ нужен программистам, чтобы они знали, что должны сделать. V>ТЗ нужен заказчику, чтобы он заранее знал, что получит в конце разработки. V>ТЗ нужен для того, чтобы сторонний человек мог разобраться в деталях функционирования готового проекта.
V>Итак, имеем три основных проектных документа: V>1. BRD — что хотел заказчик. V>2. SRS — как желаения заказчика были интерпретированы. V>3. TDS — как надо реализовать интерпретацию желаний заказчика.
Это оличный подход. Строго формализованный и т.п. Но это не водопад
Но это к слову.
Здравствуйте, denis miller, Вы писали:
DM>То есть цель ТЗ — узнать что делать?
У ТЗ нет целей. ТЗ выполняет множество разных функций. И одна из функций, которую выполняет ТЗ в период составления TDS и в период написания кода — это разъяснить программисту, что он должен сделать. До этих периодов и после них SRS выполняет другие важные функции.
Здравствуйте, denis miller, Вы писали:
V>>Итак, имеем три основных проектных документа: V>>1. BRD — что хотел заказчик. V>>2. SRS — как желаения заказчика были интерпретированы. V>>3. TDS — как надо реализовать интерпретацию желаний заказчика.
DM>Это оличный подход. Строго формализованный и т.п. Но это не водопад
Почему?
DM>Только зачем это делать?
Чтобы работать успешно и эффективно
Ты, видимо, намекаешь, что agile всегда работает эффективнее водопада. Это не так. Есть случаи, когда эффективнее гибкие процессы, а есть когда эффективнее водопад. Мое мнение, что если можно на некотором проекте применить водопад, то именно его и надо использовать. Если же водопад по разным причинам на данном проекте забуксует, то тогда agile.
Здравствуйте, denis miller, Вы писали:
DM>Пример не очень подходит. Отвечу просто — а может у них цели разные?
У кого "у них"? У вас с заказчиком? Разумеется они разные. И что?
DM>>>Не только программировать их бизнес, но знать и быть в их бизнесе? G>>Знание и понимание их бизнеса — слишком широко берете. Вам заказчики платят не за это. Они платят вам за то, что вы делаете ровно то, что им нужно — даже если они сами не могут это сформулировать, а не за совместные пьянки, и на за разговоры по душам. Более того, они были бы благодарны вам за то, что вы не заставляете их это формулировать. Именно поэтому вам и платят — потому что у заказчика в частности нет специалистов по составлению ТЗ и анализу требований. DM>Вот поэтому получается то, что получается.
У всех получается по разному. У нас проблем с заказной разработкой не было, после того как мы начали анализ проводить. Куда-то все изчезли почему-то сразу.
DM>Уверяю — заказчик не быдла, он хочет успеха. Только вопрос — хотите ли его вы?
Я не считаю заказчика "быдлой". Я вам говорю о том, что для заказчика глупость держать у себя профессионала в штате, обученного составлять ТЗ и грамотно ставить задачу. Он нужен один раз, при выполнении вашего заказа. Поэтому, его должны предоставить вы. Ну, можно конечно сетовать на несправедливость жизни и плохие методологии — как вариант.
DM>Мне вот не понятен одно, а зачем ТЗ ? (не путить с визион-документом в 2-3 странички, а подробное, верифицированное, ревьюированное и всякие бузззвордс слова).
Странный вопрос. Зачем заключают письменные договора для фиксации сделок и договоренностей? Чтобы избежать разного толкования условий сделки вами и заказчиком. ТЗ — приложение к вашему договору с заказчиком, защищает вас от изменений ключевых требований, защищает вас и заказчика от проблем на приемке, фиксирует единое понимание scope-а работ и требования к результату, фиксирует количество и сроки этапов работ.
Оплата происходит по окончании каждого этапа, по подписании акта сдачи-приемки работ. Приложением к ТЗ идет план-график, где указана стоимость этапов, описывает результаты каждого этапа, и указывает, какая работа проводится на каждом этапе.
Здравствуйте, fuurin, Вы писали:
V>> Но для тех проектов, которые мы выполняем и в тех условиях, с теми заказчиками — он работает очень хорошо.
F>Круто. А какая отрасль (я так понял, что вы специализируетесь на чём-то),
Да отрасль то самая обычная — я описал работу IT отдела одной ооочень крупной международной компании.
Основная специфика в том, что команды очень распределены. Стандартная ситуация, когда проект разрабатывает одна команда, после окончания разработки делает хендовер другой команде (которая будет заниматься новыми фичами и фиксом багов), а саппорт на продакшене осуществляет третья. Причем все три команды находятся в разных странах, а иногда и континентах. В таких условиях проект без актуальной и полной документации — это мертворожденный проект, он просто никому не нужен.
F>какой длительности проекты,
Проекты есть разные, длинные и не очень. Лично я работаю а тех, что не очень. Это порядка двух человеко-лет работы программистов.
F>как долго применяете эту схему?
G>Есть два вида разработки ПО — разработка (коробочного) продукта, и разработка на заказ под нужды внешнего заказчика.
Гм, как мне кажется, есть еще один вид разработки ПО — когда заказ дается на разработку, а на самом деле имеется в виду НИИКР. Т.е., по сути, заказчик приходит и ставит цель. Не факт, что вообще выполнимую. И хочет для реализации этой цели получить готовый продукт (а не постановку для его создания).
Возможно, взятие таких заказов есть большой прокол того менеджера, который согласился (и уж тем более который согласился на fixed cost), но для начальника разработки это не облегчает задачу.
(Разные слова про оторванность development и sales во многих компаниях опустим).
Так как задача чисто НИРовская, то ее осмысленно делать чередой развивающихся прототипов, что сейчас проще описать в терминах agile (как более популярных). Да и драйва чуть больше.
P.S. С внутренними продуктами тоже все забавно — у меня были случаи, когда внутренние заказчики (т.е. будущие пользователи системы) сначала выдвигали одни требования, даже подписывались под ними, потом меняли на полностью противоположные — и так раза три.
Впрочем, это, разумеется, тоже при разработке продукта, для всех участников "нового", т.е. исследовательских работ.
Гм, а часто ли встречаются задачи, которые не являются исследовательскими?
Здравствуйте, Дельгядо Филипп, Вы писали:
G>>Есть два вида разработки ПО — разработка (коробочного) продукта, и разработка на заказ под нужды внешнего заказчика.
ДФ>Гм, как мне кажется, есть еще один вид разработки ПО — когда заказ дается на разработку, а на самом деле имеется в виду НИИКР. Т.е., по сути, заказчик приходит и ставит цель. Не факт, что вообще выполнимую. И хочет для реализации этой цели получить готовый продукт (а не постановку для его создания).
Ок, берем стандартный ГОСТосвский классификатор. НИР, НИОКР, ОКР.
Сложные госзаказы заказы бьются на серию проектов. Часто выдают НИР на разработку технических требований, результат которого — ТЗ. НИР управляется совсем не так, как ОКР — там другие правила. Во время НИР вы можете делать прототипы и вообще — все, что сочтете необходимо для разработки ТЗ, однако, результатом и целью работ является именно скорейшее создание корректного ТЗ, т.е. получение знания, а не получение каких-либо продуктов. Грубо говоря, такой НИР впрямую соответствует фазе Inception в RUP.
Можно завести НИОКР — если кроме знания требуется концептуальный прототип, доказывающий и демонстрирующий возможности. К нему требования — он должен именно доказывать и демонстрировать, а не быть продуктом промышленного качества, что опять-таки накладывает серьезный отпечаток на процесс разработки — требованиями управлять надо, а во на качестве и функицональной полноте надо экономить. Хотя, формулировка НИОКР чрезвычайно гибка — таким образом можно обозвать и ОКР (где требуется промышленное качество и полная функциональность) с большой долей исследовательских работ. Однако, такой большой НИОКР желательно бить на более мелкие НИР и ОКР — просто потому, что так правильно делать — эффективные методы управления исследованиями и разработкой кардиналоно различаются. Например, продолжительность и трудозатраты на НИР сложно оценить, нет методик — их надо просто ограничивать по общему времени, сделать акцент на целеполагание, и вести итеративно. А вот разработку по известному функционалу (ОКР) довольно просто оценить и запланировать — так надо этим пользоваться, почему нет?
ДФ>Возможно, взятие таких заказов есть большой прокол того менеджера, который согласился (и уж тем более который согласился на fixed cost), но для начальника разработки это не облегчает задачу.
Отнюдь, почему же то прокол. Просто надо отдавать себе отчет, чем НИР от ОКР отличается и применять разные подходы для них. НИР в рамках госзаказов, разумеется, делается только по fixed cost. И это правильно. НИР который нельзя планировать и который рискован по сравнению с ОКР — может не принести результатов, надо обязательно ограничивать по времени и бюджету — это элементарное управление рисками. Надо отдавать себе отчет, какой суммой вы готовы рискнуть — любой менеджер вам это скажет сразу, что если до такой суммы — то нормально, а вот больше такой — это уже извините, мы себе позволить на "фундаментальную науку" не можем. НИР, который занимает неограниченную сумму, в бизнесе не нужен.
ДФ>(Разные слова про оторванность development и sales во многих компаниях опустим). ДФ>Так как задача чисто НИРовская, то ее осмысленно делать чередой развивающихся прототипов, что сейчас проще описать в терминах agile (как более популярных). Да и драйва чуть больше.
Я понимаю, что инженерам хочется думать о своей работе как о чем-то высоком, но "чисто НИРовских" задач в бизнесе практически не бывает — их мало. Подавляющее большинство занимается комбинированием существующих технологий (что хайтеком строго говоря не является), а не их изобретением. Обыкновенно (если компания не технический стартап, и ее инвестор — не венчурный фонд), бюджет делится в пропорции 80% на мйнстрим (ОКР), не более 20% (обычно существенно меньше — не все вообще могут себе позволить бюджеты на НИР — это большой риск) на перспективные направления и инновации (НИР). При этом, менеджмент заинтересован одновременно в увеличении эффективности НИР и сокращении затрат на них — что ведет к акценту на целеполагание и запрету на полномасштабную разработку в рамках НИР.
Описывая всю разработку в терминах agile вы по сути обманиваете менеджмент. Вы стираете границу между НИР и ОКР, убиваете на крупном уровне управление рисками, и подводите свою организацию под значительные риски.
ДФ>P.S. С внутренними продуктами тоже все забавно — у меня были случаи, когда внутренние заказчики (т.е. будущие пользователи системы) сначала выдвигали одни требования, даже подписывались под ними, потом меняли на полностью противоположные — и так раза три.
Симптом отсутствия управления требованиями . Внутренний заказчик не является специалистом ни в сборе и формулировке требований, ни в их анализе. Вы же предполагаете, что полные и непротиворечивые требования должны появиться как-то сами собой. Естественно, этого не происходит.
ДФ>Впрочем, это, разумеется, тоже при разработке продукта, для всех участников "нового", т.е. исследовательских работ. ДФ>Гм, а часто ли встречаются задачи, которые не являются исследовательскими?
Их в нашем деле подавляющее большинство. Не надо путать технологию и науку. Если не знать технологию сбора кубика-рубика — то его сборка тоже бешеный креатив. Если каждый раз изобретать все заново — то жизнь ваша будет увлекательна, конечно. Но вы проиграете.
G>Здравствуйте, Gaperton, Вы писали:
ДФ>>Гм, а часто ли встречаются задачи, которые не являются исследовательскими? G>Их в нашем деле подавляющее большинство. Не надо путать технологию и науку. Если не знать технологию сбора кубика-рубика — то его сборка тоже бешеный креатив. Если каждый раз изобретать все заново — то жизнь ваша будет увлекательна, конечно. Но вы проиграете.
Похоже, я что-то не уловил в терминологии. По моему опыту (специфическому), зачастую заказчик (внешний или внутренний — не важно), заказывая "автоматизацию" или "новую систему управления корпоративным порталом" предполагает решение вполне конкретных целей (улучшение управляемости, увеличение потока пользователей, снижения складских запасов и т.п.).
И первая стадия проекта, по идее, должна быть "исследовательской" — на ней нужно понять, как именно заказчик может выполнить свои цели и какие технические средства ему могут помочь.
Логично в этом случае, как и рекомендуют ГОСТы, сделать сначала НИР, результатом которого будет ТЗ
(правда, не понятно, кто будет этот результат принимать — специалистов такого класса у заказчика скорее всего нет).
Но это, в общем, идеальный случай разумных отношений с заказчиком.
Но, опять-таки, часто встречаются случаи, когда один менеджер продал другому "систему автоматизации, которая решит все ваши проблемы", а даже цели автоматизации в договоре не прописаны — вот тут и начинается вполне обычное веселье — как впихнуть и исследование и собственно разработку в один проект. При этом, по традиции, сроки сжатые.
Вот в этом случае мне представляется разумным начинать с итеративной разработке прототипов (как в НИР и предполагается), держа в голове перерастание этих прототипов в промышленную систему. И в качестве "процесса" для такой разработке подходят некоторые идеи agile (малые команды, тесная коммуникация с заказчиком, ранняя интеграция, постоянное тестирование, приоритезирование и т.п.).
Но, конечно, с проектированием (предварительным) и управлением требованиями (по мере их появления и если вообще это удается делать — я провалил (или вытянул очень большими усилиями) не один проект, прежде чем не осознал важность управления требованиями.
P.S. А что, бывают проекты, в которых выработка ТЗ формально вынесена в отдельный проект, а оценка общего результат происходит по результатам формирования ТЗ? Т.е. в идеале такие есть — но я о них не слышал.
G>Например, продолжительность и трудозатраты на НИР сложно оценить, нет методик — их надо просто ограничивать по общему времени, сделать акцент на целеполагание, и вести итеративно. А вот разработку по известному функционалу (ОКР) довольно просто оценить и запланировать — так надо этим пользоваться, почему нет?
G>Отнюдь, почему же то прокол. Просто надо отдавать себе отчет, чем НИР от ОКР отличается и применять разные подходы для них. НИР в рамках госзаказов, разумеется, делается только по fixed cost. И это правильно. НИР который нельзя планировать и который рискован по сравнению с ОКР — может не принести результатов, надо обязательно ограничивать по времени и бюджету — это элементарное управление рисками.
А если договор с fixed-price на НИР+ОКР вместе? Т.е. одна общая сумма и на то, и на другое. Или есть методики, которые позволяют корректно разделить общие затраты на стадии и определить, когда нужно прекращать НИР?
G>Я понимаю, что инженерам хочется думать о своей работе как о чем-то высоком, но "чисто НИРовских" задач в бизнесе практически не бывает — их мало.
Задача исследовательская не с технической точки зрения (там как раз все обычно очевидно), а с точки зрения удовлетворения потребностей новым способом.
G>Описывая всю разработку в терминах agile вы по сути обманываете менеджмент. Вы стираете границу между НИР и ОКР, убиваете на крупном уровне управление рисками, и подводите свою организацию под значительные риски.
Угу. Я по сути вкладываю консалтинг, сбор требований, выработку ТЗ внутрь проекта. Раз уж не удалось сделать их вне проектных условий.
G>Симптом отсутствия управления требованиями . Внутренний заказчик не является специалистом ни в сборе и формулировке требований, ни в их анализе. Вы же предполагаете, что полные и непротиворечивые требования должны появиться как-то сами собой. Естественно, этого не происходит.
Ну, на получение разумных требований от заказчика я уже давно не рассчитываю. Но что при описании предметной области специалист может ошибиться трижды (увы, проверить по другим источникам это было невозможно, очень узкая специализация) — этого я не предполагал. Но управления требованиями — да, не было. Впрочем, в таких задачах оно бы и не помогло.
Здравствуйте, Дельгядо Филипп, Вы писали:
G>>Здравствуйте, Gaperton, Вы писали:
ДФ>>>Гм, а часто ли встречаются задачи, которые не являются исследовательскими? G>>Их в нашем деле подавляющее большинство. Не надо путать технологию и науку. Если не знать технологию сбора кубика-рубика — то его сборка тоже бешеный креатив. Если каждый раз изобретать все заново — то жизнь ваша будет увлекательна, конечно. Но вы проиграете.
ДФ>Похоже, я что-то не уловил в терминологии. По моему опыту (специфическому), зачастую заказчик (внешний или внутренний — не важно), заказывая "автоматизацию" или "новую систему управления корпоративным порталом" предполагает решение вполне конкретных целей (улучшение управляемости, увеличение потока пользователей, снижения складских запасов и т.п.). ДФ>И первая стадия проекта, по идее, должна быть "исследовательской" — на ней нужно понять, как именно заказчик может выполнить свои цели и какие технические средства ему могут помочь.
Ну да.
ДФ>Логично в этом случае, как и рекомендуют ГОСТы, сделать сначала НИР, результатом которого будет ТЗ ДФ>(правда, не понятно, кто будет этот результат принимать — специалистов такого класса у заказчика скорее всего нет). ДФ>Но это, в общем, идеальный случай разумных отношений с заказчиком.
Заказчик, разумеется, такой НИР (который, в общем, на самом деле не НИР — это простое обследование) не оплатит. По крайней мере, сразу. Однако это не повод не заслать к нему аналитиков — вы потом затраты на обследование можете включить в общий счет работ первого этапа.
ДФ>Но, опять-таки, часто встречаются случаи, когда один менеджер продал другому "систему автоматизации, которая решит все ваши проблемы", а даже цели автоматизации в договоре не прописаны — вот тут и начинается вполне обычное веселье — как впихнуть и исследование и собственно разработку в один проект. При этом, по традиции, сроки сжатые.
В этом случае тем более надо проводить обследование за свой счет. Чтобы понять, какой фронт работ предстоит.
ДФ>Вот в этом случае мне представляется разумным начинать с итеративной разработке прототипов (как в НИР и предполагается), держа в голове перерастание этих прототипов в промышленную систему. И в качестве "процесса" для такой разработке подходят некоторые идеи agile (малые команды, тесная коммуникация с заказчиком, ранняя интеграция, постоянное тестирование, приоритезирование и т.п.).
Объясните мне, с каким "заказчиком" вы собираетесь коммуницировать с случае корпоративной ИС где 15 ролей пользователей, и менеджмент не знает деталей и нюансов работы исполнителей? А директор вообще не имеет представления о деталях фактических бизнес-процессов (ему по должности не положено в такие детали вникать)?
Суть обследования, которое надо провести перед началом разработки (если конечно переделывать ничего не хочется, что видимо и есть источник нескончаемого фана при agile разработке), и состоит в этом "общении" с заказчиком, выявлении фактических ролей, выявление фактического документооборота и бизнес-операций. О которых никто кроме непосредственных исполнителей точной и достоверной информацией не обладает. Не надо с менеджментом общаться для анализа бизнес-процессов — категорически нет. А то будете по двадцать пять раз "спринты" крутить. С исполнителями надо говорить.
В ходе обследования вы собираете заполненные формы всех документов, и беседуете с двумя исполнителями для каждой роли. С каждым их них — по часу, максимум два. Это необходимо для того, чтобы костяк системы выстроить, по которой вы любой наперед заданный отчет менеджменту сделаете.
ДФ>Но, конечно, с проектированием (предварительным) и управлением требованиями (по мере их появления и если вообще это удается делать — я провалил (или вытянул очень большими усилиями) не один проект, прежде чем не осознал важность управления требованиями.
Если вы не проводили обследования — то как именно вы требованиями управляли? Собирали то их как?
ДФ>P.S. А что, бывают проекты, в которых выработка ТЗ формально вынесена в отдельный проект, а оценка общего результат происходит по результатам формирования ТЗ? Т.е. в идеале такие есть — но я о них не слышал.
Бывают при гособоронзаказе. Цитирую мануал по составлению ТЗ на военные НИР для изделий электронной техники:
2. Цели и задачи НИР
В разделе приводят задачи, на решение которых направлена НИР, и предполагаемые пути реализации ее результатов (постановка прикладных НИР, ОКР, и т.д.)
...
3. Требования к выполнению НИР
...
В конце раздела указывают, чем должна заканчиваться работа (разработкой рекомендаций и предложений по реализации результатов НИР, проекта ТЗ на ОКР, нормативно-технических документов)
G>>Например, продолжительность и трудозатраты на НИР сложно оценить, нет методик — их надо просто ограничивать по общему времени, сделать акцент на целеполагание, и вести итеративно. А вот разработку по известному функционалу (ОКР) довольно просто оценить и запланировать — так надо этим пользоваться, почему нет?
G>>Отнюдь, почему же то прокол. Просто надо отдавать себе отчет, чем НИР от ОКР отличается и применять разные подходы для них. НИР в рамках госзаказов, разумеется, делается только по fixed cost. И это правильно. НИР который нельзя планировать и который рискован по сравнению с ОКР — может не принести результатов, надо обязательно ограничивать по времени и бюджету — это элементарное управление рисками.
ДФ>А если договор с fixed-price на НИР+ОКР вместе? Т.е. одна общая сумма и на то, и на другое. Или есть методики, которые позволяют корректно разделить общие затраты на стадии и определить, когда нужно прекращать НИР?
Следуйте циклу РУП. Он гласит, что стадии у вас как минимум четыре.
1. Завершается, когда вы на 90% имеете общее представление (во всей команде и вместе с заказчиком) о том, что надо делать. Я так понял — это и есть цель вашей НИР?
2. Завершается, когда вы на 90% имеете общее представление о том, как это надо делать. Это уже при знакомых технологиях и инструментах — обыкновенно хардкорный ОКР.
3. Завершается, когда вы даете первую полнофункицональную версию для тестирования. Тут никаким НИР уже давно не пахнет тем более.
4. Завершается, когда вы даете рабочую версию.
На первую фазу выделите для начала некоторое разумное время, скажем, неделя. В конце недели подведите итоги, и решите, вы вышли из фазы, или нет. Если нет — поставьте себе конкретные цели на следующую неделю, и повторяйте. Заранее ограничьте deadline, к которому вы должны уложиться с первой фазой, чтобы хоть как-то уложиться в общие сроки. Поставьте себе цель номер 1 — первым делом очертить хотя бы scope работ, чтобы как можно быстрее оценить масштаб работы.
G>>Я понимаю, что инженерам хочется думать о своей работе как о чем-то высоком, но "чисто НИРовских" задач в бизнесе практически не бывает — их мало. ДФ>Задача исследовательская не с технической точки зрения (там как раз все обычно очевидно), а с точки зрения удовлетворения потребностей новым способом.
Понятно.
G>>Описывая всю разработку в терминах agile вы по сути обманываете менеджмент. Вы стираете границу между НИР и ОКР, убиваете на крупном уровне управление рисками, и подводите свою организацию под значительные риски.
ДФ>Угу. Я по сути вкладываю консалтинг, сбор требований, выработку ТЗ внутрь проекта. Раз уж не удалось сделать их вне проектных условий.
Это вполне нормально на мой взгляд. Сами так делали.
G>>Симптом отсутствия управления требованиями . Внутренний заказчик не является специалистом ни в сборе и формулировке требований, ни в их анализе. Вы же предполагаете, что полные и непротиворечивые требования должны появиться как-то сами собой. Естественно, этого не происходит.
ДФ>Ну, на получение разумных требований от заказчика я уже давно не рассчитываю. Но что при описании предметной области специалист может ошибиться трижды (увы, проверить по другим источникам это было невозможно, очень узкая специализация) — этого я не предполагал. Но управления требованиями — да, не было. Впрочем, в таких задачах оно бы и не помогло.
Есть книга такая — SADT называется. Так вот, там кроме самой нотации SADT(IDEF0) описывается в деталях, как должен вести себя аналитик на интервью, чтобы заказчику было непросто всякий балшыт на уши аналитику вешать. Очень рекомендую, мне в свое время эта книга сильно помогла.
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>Собственно, минимизация издержек -- и есть самая суть agile, при определенной трактовке, разделяемой не всеми. (При этой трактовке) в этом они очень родственны с lean product development / lean manufacturing, родившимися из TPS (Toyota Production System).
Это декларируемые цели. Так сказать кто угодно может. Каким образом они доказывают, что они на самом деле минимизируют издержки? Это совершенно не очевидно. Скажем, из описания PSP/TSP совершенно очевидно, каким образом производится оптимизация процесса разработки для минимизации издержек, и за счет чего. Сам процесс позволяет объективным образом измерять собственную эффективность, да и посылки там понятны. Сама суть PSP/TSP — оптимизация процесса разработки, даже не сам процесс.
А в случае agile — почему издержки минимизируются? С какой стати мне нужно верить каким-то дядькам на слово, что если я не напишу дизайн-документ, то у меня разработка пойдет быстрее, если я видел на практике кучу контрпримеров? Если я своими глазами видел факты, доказывающие обратное — например, статистики по цене исправления дефектов, и корелляции стоимости исправления дефектов со временем между их внесением и обнаружением и фазой внесения?
Здравствуйте, Gaperton, Вы писали:
G>Заказчик, разумеется, такой НИР (который, в общем, на самом деле не НИР — это простое обследование) не оплатит. По крайней мере, сразу. Однако это не повод не заслать к нему аналитиков — вы потом затраты на обследование можете включить в общий счет работ первого этапа.
Э, про обследование существующих бизнес-процессов я тут не говорю, это само собой разумеется (хотя и не всегда удавалось их провести — но я тогда был маленький и неопытный, не умел заставить показать пользователей системы).
У меня значительная часть проектов была связана с тем, что существующие процессы не устраивают заказчика, и вместе с автоматизацией меняются и алгоритмы работы. Т.е. нужно автоматизировать не то, что есть, а то, что должно быть.
И собственно НИР — это построение картинки того, что должно быть. Включая, возможно, всякие навороты.
Ну,например, у заказчика высокие остатки на складах, долгая доставка, много затрат человекочасов на планирование логистики и низкое качество планирования.
Требуется (т.е. уже продано) решение, которое за счет некого алгоритма планирования решит указанные проблемы (т.е. автоматическое построение планов отгрузки, например, на основании информации из астрала). Алгоритмов готовых у заказчика нет, есть общие идеи, применимость которых нужно проверять.
Но проект — fixed-price.
Вот в этом случае, на мой взгляд, постоянное общение с заказчиком (с реальными будущими пользователями), регулярные билды, которые смотрят те же пользователи с реальными данными — необходимы.
ДФ>>Вот в этом случае мне представляется разумным начинать с итеративной разработке прототипов (как в НИР и предполагается), держа в голове перерастание этих прототипов в промышленную систему. И в качестве "процесса" для такой разработке подходят некоторые идеи agile (малые команды, тесная коммуникация с заказчиком, ранняя интеграция, постоянное тестирование, приоритезирование и т.п.).
G>Объясните мне, с каким "заказчиком" вы собираетесь коммуницировать с случае корпоративной ИС где 15 ролей пользователей, и менеджмент не знает деталей и нюансов работы исполнителей? А директор вообще не имеет представления о деталях фактических бизнес-процессов (ему по должности не положено в такие детали вникать)?
Есть два варианта. Или с "ответственным за проект" с той стороны — а уж он достанет нужных людей с нужных уровней.
Или со всеми 15ью ролями пользователей. В первый вариант я верю значительно меньше.
G>Суть обследования, которое надо провести перед началом разработки (если конечно переделывать ничего не хочется, что видимо и есть источник нескончаемого фана при agile разработке), и состоит в этом "общении" с заказчиком, выявлении фактических ролей, выявление фактического документооборота и бизнес-операций. О которых никто кроме непосредственных исполнителей точной и достоверной информацией не обладает. Не надо с менеджментом общаться для анализа бизнес-процессов — категорически нет. А то будете по двадцать пять раз "спринты" крутить. С исполнителями надо говорить.
Да кто бы спорил. Но этого достаточно, только если нужно автоматизировать имеющиеся бизнес-процессы. А если создаются новые процессы (и новые роли, и новые ответственности и т.п.) — то один раз поговорить при сборе требований — мало, нужно это делать регулярно, по мере развития проекта.
G>В ходе обследования вы собираете заполненные формы всех документов, и беседуете с двумя исполнителями для каждой роли. С каждым их них — по часу, максимум два. Это необходимо для того, чтобы костяк системы выстроить, по которой вы любой наперед заданный отчет менеджменту сделаете.
Ну, далеко не у каждой роли есть хотя бы по два исполнителя. Впрочем, в таких случаях я пытался поговорить про роль и с исполнителем и с его контрагентами/менеджером/подчиненными — для полноты картины.
Формы документов (с комментариями) — тоже разумеется. Хотя этого тоже мало, Excel формы, бывают, переделывают по два раза в месяц, нужно актуальные данные постоянно дособирать.
ДФ>>Но, конечно, с проектированием (предварительным) и управлением требованиями (по мере их появления и если вообще это удается делать — я провалил (или вытянул очень большими усилиями) не один проект, прежде чем не осознал важность управления требованиями.
G>Если вы не проводили обследования — то как именно вы требованиями управляли? Собирали то их как?
Проводил, конечно. И все формы были. 2х часов на роль, конечно, мало, в сумме где-то часов по 8 уходило, не считая последующих уточняющих вопросов.
Иногда — и гораздо больше.
ДФ>>P.S. А что, бывают проекты, в которых выработка ТЗ формально вынесена в отдельный проект, а оценка общего результат происходит по результатам формирования ТЗ? Т.е. в идеале такие есть — но я о них не слышал. G>Бывают при гособоронзаказе. Цитирую мануал по составлению ТЗ на военные НИР для изделий электронной техники:
Бывают, да. Хотя когда пришлось участвовать в одном из проектов ГАС "Выборы" (он, насколько я помню, делался по военным нормам), ТЗ писался одновременно с приемкой.
ДФ>>А если договор с fixed-price на НИР+ОКР вместе? Т.е. одна общая сумма и на то, и на другое. Или есть методики, которые позволяют корректно разделить общие затраты на стадии и определить, когда нужно прекращать НИР?
G>Следуйте циклу РУП. Он гласит, что стадии у вас как минимум четыре. G>1. Завершается, когда вы на 90% имеете общее представление (во всей команде и вместе с заказчиком) о том, что надо делать. Я так понял — это и есть цель вашей НИР? G>На первую фазу выделите для начала некоторое разумное время, скажем, неделя.
За это время можно только предметную область обрисовать (да и то далеко не всякую). Если ставить целью НИР постановку на 90% (причем только концептуальную, без пользовательских интерфейсов, без данных, только роли, сущности, существенные алгоритмы) и при постоянном контакте со всеми заинтересованными ролями — то для нормального проекта на 10 человеколет нужно не меньше месяца. Если повезет.
Обычно, впрочем, не везет и на часть вопросов по алгоритмам или нужным процессам следует ответ "сделайте, там посмотрим, подходит или нет".
Т.е. нужно делать прототип, причем, увы, заказчики очень плохо (как выяснилось) умеют понимать такую вещь как неполнофункциональный прототип. И заставить их оценить эффективность алгоритма или решения без всех рюшечек иногда просто нельзя.
Вот эта стадия и выливается в первую, вторую и третью одновременно.
G>4. Завершается, когда вы даете рабочую версию.
А вот от предыдущей до этой может пройти несколько подходов, иногда (если не постараться) с изрядным рефакторингом.
А уже если заказчик требует конкретных интерфейсных решений (которые, опять таки, на стадии 1 всяко не получить) — то и больше.
G>Есть книга такая — SADT называется. Так вот, там кроме самой нотации SADT(IDEF0) описывается в деталях, как должен вести себя аналитик на интервью, чтобы заказчику было непросто всякий балшыт на уши аналитику вешать. Очень рекомендую, мне в свое время эта книга сильно помогла.
Спасибо, почитаю. Но тут даже не вешанье на уши, просто специалист за полгода очень сильно поменял свое профессиональное мнение о некоторых вещах.
При том, что встречи с заказчиком (нижним уровнем реальных пользователей) проходили раз в месяц сессиями по два дня (заказчик в другой стране, чаще никак), с четкой фиксацией всех результатов, согласованием правильности понимания, отслеживанием взаимовлияния появлявшихся требований и т.п.
Но если бы мы сразу делали процесс более итеративным — этих проблем было бы меньше.
Если сформулировать мою позицию:
чем точнее заказчик знает, что он хочет — тем более длинные итерации может себе позволить исполнитель. Но каждая итерация, конечно, включает в себя все 4 стадии.
то, что называют agile технологиями — методики, позволяющие довести размер стадии до двух недель-месяца. Они нужны в тех случаях, когда заказчик почти совсем не представляет, что же он хочет получить.
Здравствуйте, Gaperton, Вы писали:
G>А в случае agile — почему издержки минимизируются? С какой стати мне нужно верить каким-то дядькам на слово, что если я не напишу дизайн-документ, то у меня разработка пойдет быстрее, если я видел на практике кучу контрпримеров?
А почему ты считаешь, что agile безусловно призывает не писать дизайн-документы?
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, Gaperton, Вы писали:
G> Если это именно продукт, который будет продаваться, то тогда не дай вам бог требования от маркетинга прощелкать, и не протестировать на соответствие. У вас в случае разработки собственного продукта по собственным требованиям есть все возможности по грамотному управлению требованиями и для предварительного проектирования.
Кроме случаев, когда условия рынка меняются: ну не нужна рынку сегодня фича X, запланированная пол-года назад, когда проект начинался, зато нужна фича Y, которую тогда никто не предсказал... К сожалению, это типичная картина:
Even if the customers can fix their requirements, the business world isn't going to stop for them. And many changes in the business world are completely unpredictable: anyone who says otherwise is either lying, or has already made a billion on stock market trading.
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, Павел Кузнецов, Вы писали:
G>> Если это именно продукт, который будет продаваться, то тогда не дай вам бог требования от маркетинга прощелкать, и не протестировать на соответствие. У вас в случае разработки собственного продукта по собственным требованиям есть все возможности по грамотному управлению требованиями и для предварительного проектирования.
ПК>Кроме случаев, когда условия рынка меняются: ну не нужна рынку сегодня фича X, запланированная пол-года назад, когда проект начинался, зато нужна фича Y, которую тогда никто не предсказал... К сожалению, это типичная картина: ПК>
ПК>Even if the customers can fix their requirements, the business world isn't going to stop for them. And many changes in the business world are completely unpredictable: anyone who says otherwise is either lying, or has already made a billion on stock market trading.
Это не типичная картина. Это балшыт. Требования всегда делатся на стопудовые, вероятные, и сомнительные, причем процент последних крайне невелик — и можно заранее заложиться на их изменение. Обсуждаемая проблема решается стратегическим маркетингом. Если вы не имеете понятия, что это такое, не имеете планов хотя бы на 4-5 лет, не имеете роадмапа и стратегии — то тогда конечно проблема лежит за пределами вашего контроля. Почему, черт возьми, мы знали за полгода по принятия приказа Реймана, когда чиновники еще сами этого не знали, что в качестве стандарта телевизионного вещания будет выбран DVB c кодированием H.264? А вот НИИМА Прогресс пролелел — заложился на MPEG2. Почему мы смогли предсказать ситуацию, а они нет? Потому что требования непредсказуемые — зависят типа от наших дурных на голову чиновников? Или все-таки потому, что у нас есть эффективная система технического маркетинга, и мы заранее просчитали вероятность этого варианта как 90%? Да ладно мы — мы то мелочь и ламеры — почему IBM в конце 80-х знал, как будут выглядеть суперкомпьютеры в 2000 году, и заранее изменил стратегию, неторопливо прорабатывая софт и технические проблемы на симуляторах, а Cray тихо загнулся, и был выкуплен Silicon Graphics?
Фаулер зачем-то приводит кривой пример про трейдеров (по ходу, даже у трейдеров есть методики прогнозирования — те, кто ими не пользуется — проигрывает, я не понаслышке знаком с работой трейдера), когда можно сказать прямо реальное положение вещей, не прибегая к дурацким аналогиям. Те компании, которые умеют предсказывать потребности рынка на срок 4-5 лет вперед и больше — зарабатывают деньги на продакт девелопменте. И не обязательно миллиарды — для нишевых продуктов будет поняное дело меньше. Те кто не умеют, не имеют грамотного маркетинга, не покупают маркетинговых отчетов, не следят за тенденциями, и не выполняют прогноза будущего на базе анализа сценариев — плетутся в хвосте и ищут себе разнообразные оправдания, в виде неожиданно меняющихся требований и неудобных процессов разработки. Выигрывает всегда тот, кто успешно работает на опережение — цикл разработки в хайтеке длинный. Впрочем, это условие необходимо, но не является достаточным.
Видите ли, есть две категории людей — одни изменяют мир по себя, другие подстраиваются под окружающий мир. Что важнее — исключить дорогие ошибки в требованиях раньше и иметь точные планы по бюджетам и рискам — или сразу встать лапками кверху и стараться удешевить внесение ad hoc изменений, адаптируясь к бестолковости собственных служб маркетинга? Это взаимоисключающие подходы. В одном случае вы делаете ставку на улучшение планирования, что позволяет вам эффективно управлять портфелем проектов, а не одним, в другом — адаптируетесь к хаосу. Первый подход — эффективнее. На портфеле проектов в long term будет однозначно четкий выигрыш. Второй подход снизит максимальную цену промаха по отдельному проекту, но на портфеле проектов вы получите худший суммарный результат.
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>Здравствуйте, Gaperton, Вы писали:
G>>А в случае agile — почему издержки минимизируются? С какой стати мне нужно верить каким-то дядькам на слово, что если я не напишу дизайн-документ, то у меня разработка пойдет быстрее, если я видел на практике кучу контрпримеров?
ПК>А почему ты считаешь, что agile безусловно призывает не писать дизайн-документы?
Во первых. Ну положим в ХР, который ты мне недавно приводил, совершенно точно провозглашается преимущество рефакторинга перед предварительным проектированием, выполнять которое запрещено прямо. То же самое является чертой всей группы agile. Am I wrong?
Во вторых. Дело не в том, что дизайн-документ писать запрещено или не запрещено. Вопрос — какую роль этот документ играет в процессе разработки? Если никакой, то и толку от его написания нет никакого — зачем писать документы в стол, которые процесс не предусматривает использовать? Покажи мне ссылку, где указан жизненный цикл и правила использования дизайн документа в рамках agile. Посмотрим на это.
В третьих — раз предполагается, что ты знаешь эту истину — почему бы тебе не сформулировать по возможности математически точно, избегая магических пассов руками, общих фраз, и ссылок на манифесты agile, в чем состоит фундаментальное практическое отличие процесса agile от классики? Чего там делается такого нового — конкретно и четко? Или чего не делается. От общей философии и деклараций, на что направлены agile подходы, я устал. "Мы, сыщики, должны изъясняться существительными и глаголами, — он пришел, она сказала, он ответил". Балшыт давай оставим авторам книг.
Здравствуйте, Дельгядо Филипп, Вы писали:
G>>Заказчик, разумеется, такой НИР (который, в общем, на самом деле не НИР — это простое обследование) не оплатит. По крайней мере, сразу. Однако это не повод не заслать к нему аналитиков — вы потом затраты на обследование можете включить в общий счет работ первого этапа.
ДФ>Э, про обследование существующих бизнес-процессов я тут не говорю, это само собой разумеется (хотя и не всегда удавалось их провести — но я тогда был маленький и неопытный, не умел заставить показать пользователей системы). ДФ>У меня значительная часть проектов была связана с тем, что существующие процессы не устраивают заказчика, и вместе с автоматизацией меняются и алгоритмы работы. Т.е. нужно автоматизировать не то, что есть, а то, что должно быть. ДФ>И собственно НИР — это построение картинки того, что должно быть. Включая, возможно, всякие навороты.
Это реинжиниринг бизнес-процессов, который вообще-то лежит вне контекста автоматизации. Совершенно отдельная работа. Выполняется специально обученными консультантами, а не программистами. Это, если угодно, совершенно отдельный НИР.
Кстати, позвольте вам не поверить, что вам его обычно специально заказывают и оплачивают клиенты. Наиболее вероятно, что они его инициируют самопроизвольно, когда вы начинаете докладывать менеджменту результаты вашего обследования. Что, разумеется, сразу вызывает кипучую деятельность, и тормозит вашу работу. На моей памяти был случай, когда такое "вовлечение заказчика" привело к полному срыву контракта на автоматизацию.
ДФ>Ну,например, у заказчика высокие остатки на складах, долгая доставка, много затрат человекочасов на планирование логистики и низкое качество планирования. ДФ>Требуется (т.е. уже продано) решение, которое за счет некого алгоритма планирования решит указанные проблемы (т.е. автоматическое построение планов отгрузки, например, на основании информации из астрала). Алгоритмов готовых у заказчика нет, есть общие идеи, применимость которых нужно проверять.
А идеи заглянуть в учебник по управлению товарными остатками — не возникало? У вас, конечно, у заказчика понятно что нет.
ДФ>Но проект — fixed-price. ДФ>Вот в этом случае, на мой взгляд, постоянное общение с заказчиком (с реальными будущими пользователями), регулярные билды, которые смотрят те же пользователи с реальными данными — необходимы.
Алгоритм и бизнес-правила согласуются дешевле и быстрее. Для этого полнофункциональный билд излишен.
G>>Объясните мне, с каким "заказчиком" вы собираетесь коммуницировать с случае корпоративной ИС где 15 ролей пользователей, и менеджмент не знает деталей и нюансов работы исполнителей? А директор вообще не имеет представления о деталях фактических бизнес-процессов (ему по должности не положено в такие детали вникать)?
ДФ>Есть два варианта. Или с "ответственным за проект" с той стороны — а уж он достанет нужных людей с нужных уровней. ДФ>Или со всеми 15ью ролями пользователей. В первый вариант я верю значительно меньше.
Я уверен в ущербности обоих вариантов. И верю в обследование и анализ требований — эта штука не подводит.
G>>Суть обследования, которое надо провести перед началом разработки (если конечно переделывать ничего не хочется, что видимо и есть источник нескончаемого фана при agile разработке), и состоит в этом "общении" с заказчиком, выявлении фактических ролей, выявление фактического документооборота и бизнес-операций. О которых никто кроме непосредственных исполнителей точной и достоверной информацией не обладает. Не надо с менеджментом общаться для анализа бизнес-процессов — категорически нет. А то будете по двадцать пять раз "спринты" крутить. С исполнителями надо говорить.
ДФ>Да кто бы спорил. Но этого достаточно, только если нужно автоматизировать имеющиеся бизнес-процессы. А если создаются новые процессы (и новые роли, и новые ответственности и т.п.) — то один раз поговорить при сборе требований — мало, нужно это делать регулярно, по мере развития проекта.
А то я не сталкивался с этой проблемой — автоматизация во время реорганизации . Надо взять паузу, чтобы заказчик устаканил свои процессы. Разработку тормознуть, выделить заказчику аналитика. Какой смысл вести разработку постоянно переделывая?
G>>В ходе обследования вы собираете заполненные формы всех документов, и беседуете с двумя исполнителями для каждой роли. С каждым их них — по часу, максимум два. Это необходимо для того, чтобы костяк системы выстроить, по которой вы любой наперед заданный отчет менеджменту сделаете.
ДФ>Ну, далеко не у каждой роли есть хотя бы по два исполнителя. Впрочем, в таких случаях я пытался поговорить про роль и с исполнителем и с его контрагентами/менеджером/подчиненными — для полноты картины. ДФ>Формы документов (с комментариями) — тоже разумеется. Хотя этого тоже мало, Excel формы, бывают, переделывают по два раза в месяц, нужно актуальные данные постоянно дособирать.
Excel формы вам не нужны на этом этапе. Это отчеты. Вам нужна первичка, на основании которой строятся отчеты, а ее по два раза в месяц не переделывают.
ДФ>>>Но, конечно, с проектированием (предварительным) и управлением требованиями (по мере их появления и если вообще это удается делать — я провалил (или вытянул очень большими усилиями) не один проект, прежде чем не осознал важность управления требованиями.
G>>Если вы не проводили обследования — то как именно вы требованиями управляли? Собирали то их как? ДФ>Проводил, конечно. И все формы были. 2х часов на роль, конечно, мало, в сумме где-то часов по 8 уходило, не считая последующих уточняющих вопросов. ДФ>Иногда — и гораздо больше.
2 часа на роль — обычно хватало с избытком. Надо знать, что надо спрашивать, и главное — что спрашивать не надо. Вы с менеджерами поменьше говорите, и будет гораздо меньше 8 часов.
ДФ>>>P.S. А что, бывают проекты, в которых выработка ТЗ формально вынесена в отдельный проект, а оценка общего результат происходит по результатам формирования ТЗ? Т.е. в идеале такие есть — но я о них не слышал. G>>Бывают при гособоронзаказе. Цитирую мануал по составлению ТЗ на военные НИР для изделий электронной техники: ДФ>Бывают, да. Хотя когда пришлось участвовать в одном из проектов ГАС "Выборы" (он, насколько я помню, делался по военным нормам), ТЗ писался одновременно с приемкой.
Значит, в том проекте нормы нарушались. Наличие ГОСТ-оских документов не означает, что разработка ведется организовано.
ДФ>>>А если договор с fixed-price на НИР+ОКР вместе? Т.е. одна общая сумма и на то, и на другое. Или есть методики, которые позволяют корректно разделить общие затраты на стадии и определить, когда нужно прекращать НИР?
G>>Следуйте циклу РУП. Он гласит, что стадии у вас как минимум четыре. G>>1. Завершается, когда вы на 90% имеете общее представление (во всей команде и вместе с заказчиком) о том, что надо делать. Я так понял — это и есть цель вашей НИР? G>>На первую фазу выделите для начала некоторое разумное время, скажем, неделя. ДФ>За это время можно только предметную область обрисовать (да и то далеко не всякую). Если ставить целью НИР постановку на 90% (причем только концептуальную, без пользовательских интерфейсов, без данных, только роли, сущности, существенные алгоритмы) и при постоянном контакте со всеми заинтересованными ролями — то для нормального проекта на 10 человеколет нужно не меньше месяца. Если повезет.
Вам не нужен постоянный контакт со всеми ролями. Кроме того, аналитик должен уметь внимателно читать документы. Когда я сказал "неделя" — я четко сказал далее, где вы мой текст вырезали, что надо каждую неделю в течении фазы inception контроллировать прогресс и выполнять целеполагание на следующую неделю. Я ничего не сказал на тему того, для чего "достаточно" недели, а для чего нет.
ДФ>Обычно, впрочем, не везет и на часть вопросов по алгоритмам или нужным процессам следует ответ "сделайте, там посмотрим, подходит или нет".
А вы вопросы задаете по нужным процессам? Ну вы даете. Разумеется, вам так и ответят. Вы должны сами уметь процессы идентифицировать и описывать, в этом работа аналитика и состоит.
ДФ>Т.е. нужно делать прототип, причем, увы, заказчики очень плохо (как выяснилось) умеют понимать такую вещь как неполнофункциональный прототип. И заставить их оценить эффективность алгоритма или решения без всех рюшечек иногда просто нельзя. ДФ>Вот эта стадия и выливается в первую, вторую и третью одновременно.
в мало-мальски крупной компании более 5 ролей исполнителей, ни один из которых не знает полной картины. О менеджменте я вообще молчу — они нихрена не шарят в реальном положении вещей по фактическим бизнес-процессам. Вам просто некому показать, чтобы было "посмотрим", никто там не пендрит в этом, чтобы адекватно оценить вашу систему. Вы должны наверняка сработать, для этого и нужно фактические процессы с организации снять. Читайте книгу SADT, короче.
G>>4. Завершается, когда вы даете рабочую версию. ДФ>А вот от предыдущей до этой может пройти несколько подходов, иногда (если не постараться) с изрядным рефакторингом.
Значит, плохо сработали на первых этапах.
ДФ>А уже если заказчик требует конкретных интерфейсных решений (которые, опять таки, на стадии 1 всяко не получить) — то и больше.
Почему не получить? Не понимаю. У меня всегда получалось. И вообще — по моей практике это редкость, по большому счету заказчику все равно, какие будут решения, лишь бы удобно было.
G>>Есть книга такая — SADT называется. Так вот, там кроме самой нотации SADT(IDEF0) описывается в деталях, как должен вести себя аналитик на интервью, чтобы заказчику было непросто всякий балшыт на уши аналитику вешать. Очень рекомендую, мне в свое время эта книга сильно помогла.
ДФ>Спасибо, почитаю. Но тут даже не вешанье на уши, просто специалист за полгода очень сильно поменял свое профессиональное мнение о некоторых вещах. ДФ>При том, что встречи с заказчиком (нижним уровнем реальных пользователей) проходили раз в месяц сессиями по два дня (заказчик в другой стране, чаще никак), с четкой фиксацией всех результатов, согласованием правильности понимания, отслеживанием взаимовлияния появлявшихся требований и т.п.
ДФ>Но если бы мы сразу делали процесс более итеративным — этих проблем было бы меньше.
В таких условиях, когда невозможно анализ и обследование проводить — безусловно, надо вести разработку короткими итерациями. Тока на моей памяти это редкость. Заказчик, правда, всегда был в зоне досягаемости.
ДФ>Если сформулировать мою позицию: ДФ>чем точнее заказчик знает, что он хочет — тем более длинные итерации может себе позволить исполнитель. Но каждая итерация, конечно, включает в себя все 4 стадии.
Мой тезис — заказчик никогда не знает, что он хочет. У него есть общие критерии, и все. Это ваша работа, выяснить, что ему на самом деле нужно. Будете ориентироваться на то, что он хочет — это как с беременной женой. "Свари суп из говна!" Помните анекдот?
ДФ>то, что называют agile технологиями — методики, позволяющие довести размер стадии до двух недель-месяца. Они нужны в тех случаях, когда заказчик почти совсем не представляет, что же он хочет получить.
Когда вы лишены возможности выяснить, что заказчику нужно. Только тогда итерации — как последний шанс и только на первой фазе. Разделять надо "хочет" и "нужно". Над первым у вас контроля нет, над вторым — почти всегда есть.
Не все так просто, к сожалению.
Последнее время мне все больше и больше приходится сдвигаться в сторону agile (хоть оно мне вообще-то и не нравится).
И причины примерно те же, что и у Филиппа.
Попробую описать ситуацию более кратко и жестко:
делаются "системы изменяющие организацию".
То есть:
1. Система реализует новые бизнес-процессы из "основной группы".
1.а Эти бизнес-процессы являются ключевыми для организации-заказчика.
1.б Заказчик рассчитывает, что их введение даст ему существенные конкурентные преимущества => с большой вероятностью (по крайней мере в данной отрасли) они еще не применялись.
2. Эти бизнес-процессы существенно завязаны на создаваемую информационную систему.
2.а Как следствие, они зачастую не могут быть запущены заранее "на бумаге" (ниже — "психотренинг БП" полностью отделить от разработки ИС не удается, без нее он остается "теоретическим").
3. Новые бизнес-процессы ориентированы на организацию "в целом", и в полной мере не имеют смысла на отдельном подразделении или филиале.
3.а Иными словами, использование какого-то небольшого подразделения в качестве "подопытного кролика" не дает существенного снижения рисков.
3.б ИС сразу должна быть запущена под полной нагрузкой, "не полнофункциональные макеты" — не катят.
3.в Переход организации на новый режим работы штука крайне дорогая, а следовательно "возврата нет". Иными словами нельзя "попробовать" "для уточнения требований". Стоимость перехода, гораздо выше стоимости разработки ИС как таковой.
Здравствуйте, Gaperton, Вы писали: G>Это реинжиниринг бизнес-процессов, который вообще-то лежит вне контекста автоматизации. Совершенно отдельная работа. Выполняется специально обученными консультантами, а не программистами.
Да. Но результат их работы не будет завершенным НИР, а будет только "теорией", пока бизнес-процессы не "запущены".
Хорошо, если их можно запустить без ИС, но так бывает не всегда.
G>А то я не сталкивался с этой проблемой — автоматизация во время реорганизации . Надо взять паузу, чтобы заказчик устаканил свои процессы. Разработку тормознуть, выделить заказчику аналитика. Какой смысл вести разработку постоянно переделывая?
В случае, если для "устаканивания процессов" требуется наличие ИС пауза не поможет.
Случай когда "эти два дерева могут рости только вместе".
Хотя кое в чем ты и прав — характерное время изменений в организации обычно заметно больше времени написания поддерживающего софта. Так что притормаживать порой надо.
Здравствуйте, Alex EXO, Вы писали:
AE>Не все так просто, к сожалению.
Разумеется
AE>Попробую описать ситуацию более кратко и жестко: AE>делаются "системы изменяющие организацию". AE>То есть: AE>1. Система реализует новые бизнес-процессы из "основной группы". AE>1.а Эти бизнес-процессы являются ключевыми для организации-заказчика. AE>1.б Заказчик рассчитывает, что их введение даст ему существенные конкурентные преимущества => с большой вероятностью (по крайней мере в данной отрасли) они еще не применялись.
AE>2. Эти бизнес-процессы существенно завязаны на создаваемую информационную систему. AE>2.а Как следствие, они зачастую не могут быть запущены заранее "на бумаге" (ниже — "психотренинг БП" полностью отделить от разработки ИС не удается, без нее он остается "теоретическим").
Вы описываете реальную жизненную ситуацию. В которой новые бизнес-процессы должны быть зафиксированы на бумаге, и пройти серию проверок. Этого глупо не делать. Это в данном случае есть работа аналитиков и консультантов. Если их предоставляете вы — прекрасно. Если вы их не предоставляете, а фиксируете их сразу в системе (и в первый раз клиент видит их реализованным именно в вашей системе) — вы себе удваиваете косты. Как минимум.
AE>3. Новые бизнес-процессы ориентированы на организацию "в целом", и в полной мере не имеют смысла на отдельном подразделении или филиале. AE>3.а Иными словами, использование какого-то небольшого подразделения в качестве "подопытного кролика" не дает существенного снижения рисков. AE>3.б ИС сразу должна быть запущена под полной нагрузкой, "не полнофункциональные макеты" — не катят. AE>3.в Переход организации на новый режим работы штука крайне дорогая, а следовательно "возврата нет". Иными словами нельзя "попробовать" "для уточнения требований". Стоимость перехода, гораздо выше стоимости разработки ИС как таковой.
Ай-ай-ай. То есть налицо высокая цена ошибки в реализации требований, и высочайшая — в самих требованиях. Плюс принципиальная "вотерфольность" процесса. Прям как в микроэлектронике — один в один. Ну надо же. Я как менеджер в такой ситуации настоял бы на документировании планируемых бизнес-процессов и серии формалных инспекций, с целью выловить максимум ошибок на ранних этапах. Т.е. заставил бы работать так, как это делают профессионалы по реинжинирингу бизнес-процессов. Никаких agile в такой ситуации, категорически.
Льете воду на мельницу ватерфола, Алекс .
AE>Здравствуйте, Gaperton, Вы писали: G>>Это реинжиниринг бизнес-процессов, который вообще-то лежит вне контекста автоматизации. Совершенно отдельная работа. Выполняется специально обученными консультантами, а не программистами.
AE>Да. Но результат их работы не будет завершенным НИР, а будет только "теорией", пока бизнес-процессы не "запущены". AE>Хорошо, если их можно запустить без ИС, но так бывает не всегда.
Именно будет завершенным именно НИР. И одним из результатов НИР будет проект ТЗ и пожтапный план внедрения. Кстати, для большой организации практически всегда можно запускать автоматизацию потапно. Без исключений. Вы неправы, Алекс, утверждая, что надо реализовать обязательно полную функциональность. Просто этапы надо бить не по отделам и филиалам, а по "функциональным блокам". У меня плохо с памятью — но посмотрите стандарт (кажется) MRP2 — там дано такое разбиение.
G>>А то я не сталкивался с этой проблемой — автоматизация во время реорганизации . Надо взять паузу, чтобы заказчик устаканил свои процессы. Разработку тормознуть, выделить заказчику аналитика. Какой смысл вести разработку постоянно переделывая?
AE>В случае, если для "устаканивания процессов" требуется наличие ИС пауза не поможет.
В описываемом вами случае внедрение КИС является частью более крупной работы по реорганизации БП, и общую работу надо строить не по канонам разработки софта. Вот и весь фокус. Софт — это необходимый, но далеко не главный этап.
AE>Случай когда "эти два дерева могут рости только вместе". AE>Хотя кое в чем ты и прав — характерное время изменений в организации обычно заметно больше времени написания поддерживающего софта. Так что притормаживать порой надо.
Короче, Алекс, вы будете вероятно смеяться, но я абсолютно серьезен — в данной ситуации как раз показан жосткий ватерфол. По всем канонам. Agile приведет к провалу. Шляпу сожру, натурально. С точки зрения проектного управления — ситуация полностью — полностью аналогична проектам микроэлектроники.
Здравствуйте, Gaperton, Вы писали: G>Вы описываете реальную жизненную ситуацию. В которой новые бизнес-процессы должны быть зафиксированы на бумаге, и пройти серию проверок. Этого глупо не делать. Это в данном случае есть работа аналитиков и консультантов.
+1 согласен
Но при этом не забываем, что пока эти БП таки пока остаются "сферическим конем в вакууме". Даже после всех проверок.
G>Ай-ай-ай. То есть налицо высокая цена ошибки в реализации требований, и высочайшая — в самих требованиях. Плюс принципиальная "вотерфольность" процесса. Прям как в микроэлектронике — один в один. Ну надо же. Я как менеджер в такой ситуации настоял бы на документировании планируемых бизнес-процессов и серии формалных инспекций, с целью выловить максимум ошибок на ранних этапах. Т.е. заставил бы работать так, как это делают профессионалы по реинжинирингу бизнес-процессов.
Все так.
G> Никаких agile в такой ситуации, категорически.
agile работает несколько на другом уровне — нарезке на минимально осмысленные изменения. Включаяя и изменеия БП и поддерживающую разработку. "Опасные шаги" нужно сделать как можно мельче. А уж как это назвать — второй вопрос.
G> Именно будет завершенным именно НИР. И одним из результатов НИР будет проект ТЗ и пожтапный план внедрения.
Да. Почти так.
Этап 1. Описание БП. На _весь_ комплект взаимосвязанных БП.
Этап 2. Поэтапный план внедрения.
а вот дальше цикл:
3.1 ТЗ этапа
3.2 разработка блока ИС поддерживающего функционал этапа
3.3 тестипрование
3.4 _опа_! "Внимание прыгаем". Изменеие БП в организации, запуск блока ИС
3.5 опытная эксплуатация — нестабильный этап(кошмар и аврал, выворачивание всего блока на изнанку)
3.6 опытная эксплуатация — стабилизация, документирование итогового функционала, написание "журнала различий" (какие требования менялись и почему — понадобится на шаге 3.1 следующих этапов)
3.7 рефакторинг блока (причесывание того кода, который аврально менялся на этапе 3.5) под непрерывным тестированием.
3.8 "рефакторинг" общего описания комплекта БП (с шага 1)
Самым дорогим для всех здесь является шаг 3.5
И полностью исключить его обычно не удается. Лучше всего работает сокращение всего "цикла 3.*"
G> Кстати, для большой организации практически всегда можно запускать автоматизацию потапно. Без исключений. Вы неправы, Алекс, утверждая, что надо реализовать обязательно полную функциональность. Просто этапы надо бить не по отделам и филиалам, а по "функциональным блокам".
Да. Именно так.
Но только такой "функциональный блок" — это не макет. На него сразу падает полная нагрузка (в смысле числа пользователей и информационного потока).
G>В описываемом вами случае внедрение КИС является частью более крупной работы по реорганизации БП, и общую работу надо строить не по канонам разработки софта. Вот и весь фокус. Софт — это необходимый, но далеко не главный этап.
Только софт тоже нужно разрабатывать. И вот получающаяся в итоге разработка софта ("проектция" "общей работы" на плоскость разработки софта) очень сильно напоминает agile.
Спасибо за весь предшествующий диалог, от начальной темы мы несколько отклонились, но мне очень интересно.
Я все пытаюсь понять, есть ли граничные условия у применения гибких методологий и если есть — то какие (и часто ли в реальном мире они встречаются).
Все-таки, я пока еще верю, что каждому проекту — своя методология и описание методологии без граничных условий не стоит использованной бумаги.
Может быть ошибаюсь.
ДФ>>У меня значительная часть проектов была связана с тем, что существующие процессы не устраивают заказчика, и вместе с автоматизацией меняются и алгоритмы работы. Т.е. нужно автоматизировать не то, что есть, а то, что должно быть. ДФ>>И собственно НИР — это построение картинки того, что должно быть. Включая, возможно, всякие навороты. G>Это реинжиниринг бизнес-процессов, который вообще-то лежит вне контекста автоматизации. Совершенно отдельная работа. Выполняется специально обученными консультантами, а не программистами. Это, если угодно, совершенно отдельный НИР. G>Кстати, позвольте вам не поверить, что вам его обычно специально заказывают и оплачивают клиенты. Наиболее вероятно, что они его инициируют самопроизвольно, когда вы начинаете докладывать менеджменту результаты вашего обследования. Что, разумеется, сразу вызывает кипучую деятельность, и тормозит вашу работу. На моей памяти был случай, когда такое "вовлечение заказчика" привело к полному срыву контракта на автоматизацию.
По-моему, мы в разных мирах находимся. В большинстве случаев меня (на должности team-lead) ставили перед фактом заключения договора на некую работу (называемую обычно "система автоматизации {процесса|отдела|учета}) с оговоренными сроками (и суммами). Почти всегда заказчик предполагал, что в результате автоматизации будет проведен и реинжиниринг бизнес-процессов (хотя в договоре это не всегда отражалось, просто при попытке понять, а что собственно автоматизировать, из имеющегося хаоса (для внешнего наблюдателя) выявляются процессы, роли, потоки данных и т.п. — то, чего раньше вообще не было отрефлектировано. И процесс фиксации — это уже реинжиниринг).
Никаких докладов менеджменту, разумеется, не было, предполагалось (менеджментом), что каким-то образом будет построена некая система, удовлетворяющая заказчика.
Скорее всего, если иметь навыки сбора требований, аналитики, бизнес-процессов, то классический процесс будет оптимален — тут я не берусь спорить. Но в реальности этих навыков у team-lead зачастую нет и, мне кажется, то, что называют agile методологиями позволяет, за счет роста стоимости проекта, все-таки сделать хоть что-то осмысленное.
В противном случае вероятность успешного результата (проект удачно внедрен, используется и приносит пользу) очень мала.
При использовании некоторых техник agile (скорее всего неофициального использования) — есть шансы, что хоть что-то будет хорошо.
Собственно, анализируя старый опыт, я понимаю, что там, где я неофициально использовал стандартные техники agile (частые сборки, новые версии выставляемые заказчику, активную работу с заказчиком, приоритеты от заказчика) удавалось сделать хоть что-то. Там, где я делал большие части проекта, понадеявшись на "случайное" ТЗ (хотя по нему и была проведена вполне качественная работа по проектированию, планированию, кодированию) — весь результат пошел в топку.
Я не берусь сказать, насколько часто team-lead играет роль и аналитика, и бизнес-консультанта и специалиста в предметной области — но подозреваю, что ситуация, когда ему приходится это делать довольно распространена. Думаю, ситуации, когда он не умеет это делать действительно хорошо — тоже достаточно обычна. К тому же довольно нелегко team-lead признать, что он плохой аналитик и не умеет описывать бизнес-процессы. Я, например, только в процессе этого обсуждения это понял
(Да, на всякий случай, все мои примеры — с разных мест работы, с разными типами заказчиков. Объемы проектов (фактические) — единицы-десятки человеко-лет. От ERP до web-разработки).
Дальше идут мелкие примечания, вопросы и самооправдания
G>А идеи заглянуть в учебник по управлению товарными остатками — не возникало? У вас, конечно, у заказчика понятно что нет.
Обижаешь. И заказчик их хорошо знал, и мне пришлось прочитать. Просто стандартные методики не проходили по граничным условиям или эффективности.
Поэтому приходилось использовать собственные эвристики, но их нужно было очень и очень активно и неочевидно проверять.
G>Алгоритм и бизнес-правила согласуются дешевле и быстрее. Для этого полнофункциональный билд излишен.
Гм. А где-нибудь описана методика согласования бизнес-правил и алгоритмов? Просто по моему опыту есть явная проблема в языках. Формальное описание бизнес-процесса или алгоритма (со всеми условиями) не готов воспринимать заказчик (специалисты в предметной области или конкретные исполнители), а приблизительное описание (которое он может предоставить) обычно дырявое и приводит к некорректным результатам. Картинки не помогают, увы (или я их не умею рисовать — что, в общем, то же самое).
Собственно, из-за подобных коллизий многие проблемы в алгоритмах и вылезают только в полнофункциональном билде и тестировании на живых данных.
(Заметим, что предоставить живые данные до запуска многие заказчики отказываются из-за соображений секретности, а сделать корректную модель — тоже не в их силах).
G>А то я не сталкивался с этой проблемой — автоматизация во время реорганизации . Надо взять паузу, чтобы заказчик устаканил свои процессы. Разработку тормознуть, выделить заказчику аналитика. Какой смысл вести разработку постоянно переделывая?
Вот, очень важный момент. Если можно выделить аналитика, который может провести реорганизацию — то замечательно.
Но иногда единственный аналитик — это team-lead группы разработки. И в этом случае процесс реорганизации (скорее — собственно организации) происходит последовательными приближениями софта и людей. Он просто по другому, обычно, не умеет.
Но очень важно, что бы хоть кто-нибудь в этот момент понял, что происходит фигня и надо остановиться. И далеко не всегда это может быть разработчик — у него может просто не хватить кругозора (и возможности встать в рефлексивную позицию). Да и не учат этому нигде и в книжках по разработке не пишут.
G>2 часа на роль — обычно хватало с избытком. Надо знать, что надо спрашивать, и главное — что спрашивать не надо. Вы с менеджерами поменьше говорите, и будет гораздо меньше 8 часов.
Угу, в следующий раз попытаюсь поднять предложенную литературу и научиться проводить обследование. Увы, раньше не умел, сейчас работа другого профиля.
Обидно, что даже не понимал, что не умею ;(
ДФ>>>>А если договор с fixed-price на НИР+ОКР вместе? Т.е. одна общая сумма и на то, и на другое. Или есть методики, которые позволяют корректно разделить общие затраты на стадии и определить, когда нужно прекращать НИР?
G>Кроме того, аналитик должен уметь внимательно читать документы.
Опс, не понял, что "стадия"!="фаза". Но да, читать документы нужно внимательно.
Но, прошу прощения, входящие документы я обычно читаю по три раза и с карандашом, на форум вечером сил остается меньше...
ДФ>>Обычно, впрочем, не везет и на часть вопросов по алгоритмам или нужным процессам следует ответ "сделайте, там посмотрим, подходит или нет". G>А вы вопросы задаете по нужным процессам? Ну вы даете. Разумеется, вам так и ответят. Вы должны сами уметь процессы идентифицировать и описывать, в этом работа аналитика и состоит.
Гм, я правильно понял, что подтверждение корректности выделенных процессов пользователем не требуется? Я, почему-то, всегда считал, что нужно выделить, описать, а потом — согласовать правильность моего понимания.
По поводу "сделайте — там посмотрим": а какое правильное поведение в тех случаях, когда заказчик должен принять некоторое решение (выбор)?
(Например, в отделе закупок явно воруют. Предлагается менеджментом насильно внедрить систему автоматического выбора подрядчика, для этого возможно два "книжных" существенно различных подхода (сильно влияющих на проектирование). Я обычно считаю, что выбор должен сделать заказчик. Но часто звучит именно "сделайте, а там посмотрим".)
G>Почему не получить? Не понимаю. У меня всегда получалось. И вообще — по моей практике это редкость, по большому счету заказчику все равно, какие будут решения, лишь бы удобно было.
Уф, завидую. В моей практике есть проекты, задержанные на год, пока топ.менеджер выбирал цвет фона и дизайн отдельных элементов для ПО. Причем согласованные на первом этапе эскизы были проигнорированы (проект внутренний, понятное дело).
G>В таких условиях, когда невозможно анализ и обследование проводить — безусловно, надо вести разработку короткими итерациями. Тока на моей памяти это редкость. Заказчик, правда, всегда был в зоне досягаемости.
Я бы уточнил чуть-чуть: когда нельзя провести качественный анализ и обследование — то стоит вести разработку короткими итерациями.
Возможно, это хорошая оценка применимости agile техник.
Т.е. agile — от недостатка опыта/умений.
G>Мой тезис — заказчик никогда не знает, что он хочет. У него есть общие критерии, и все. Это ваша работа, выяснить, что ему на самом деле нужно.
Угу, но я долго шел до этого понимания. И, кстати, методики определения "чего ему нужно" до сих пор не знаю. Но зачастую (особенно в "авторитарных" конторах" к целям автоматизации это "что нужно" отношения не имеет...
Кстати, а действительно ли это работа аналитика? Зачастую заказчику нужно увеличить, например, обороты — и для этого он, зачем-то, заказывает веб-сайт или CRM. До заключения контракта еще можно объяснить, что для этой цели нужно нечто совсем другое. Но если заказ уже спущен — то любая деятельность не приведет к результату. Есть разумное поведение в этих случаях?
Здравствуйте, Дельгядо Филипп, Вы писали:
ДФ>Спасибо за весь предшествующий диалог, от начальной темы мы несколько отклонились, но мне очень интересно. ДФ>Я все пытаюсь понять, есть ли граничные условия у применения гибких методологий и если есть — то какие (и часто ли в реальном мире они встречаются). ДФ>Все-таки, я пока еще верю, что каждому проекту — своя методология и описание методологии без граничных условий не стоит использованной бумаги. ДФ>Может быть ошибаюсь.
Нет, вы абсолютно правы. С таким отношением у вас все будет в порядке
ДФ>По-моему, мы в разных мирах находимся. В большинстве случаев меня (на должности team-lead) ставили перед фактом заключения договора на некую работу (называемую обычно "система автоматизации {процесса|отдела|учета}) с оговоренными сроками (и суммами). Почти всегда заказчик предполагал, что в результате автоматизации будет проведен и реинжиниринг бизнес-процессов (хотя в договоре это не всегда отражалось, просто при попытке понять, а что собственно автоматизировать, из имеющегося хаоса (для внешнего наблюдателя) выявляются процессы, роли, потоки данных и т.п. — то, чего раньше вообще не было отрефлектировано. И процесс фиксации — это уже реинжиниринг).
У вас продвинутый заказчик — он понимает, что внедряемая система всегда так или иначе меняет бизнес-процессы. Это хорошо. Лет 7 назад это было в большинстве случаев не так.
ДФ>Никаких докладов менеджменту, разумеется, не было, предполагалось (менеджментом), что каким-то образом будет построена некая система, удовлетворяющая заказчика.
Я имел в виду доклады менеджменту заказчика. По моей практике, результаты обследования надо докладывать директорату заказчика очень осторожно — ведь они в первый раз увидят в деталях, как работает их контора, и могут затеять реорганизацию, начав вносить правки прямо в ваши схемы. Вот это — кирдык. У меня два заказа из-за этого сорвалось.
Один сорвался вообще фееричным образом — директор увидев первый прототип (я в 1998 году решил собрать ранний прототип системы управления производством, чтобы продемонстрировать директору заказчика с целью "появления аппетита" и увеличения бюджетов — он был умный и продвинутый, МИФИ закончил), дико протащился от заложенных решений, в том числе и интерфейсных, и налабал за неделю на Excel новую версию системы планирования производства сам (старая была тоже на Экселе). А ведь это была не простая торговая конторка с типовыми бизнес-процессами — это фабрика спортивных изделий "Леко" была, там довольно нетривиальное производство. Я вообще не предполагал, что на Экселе можно такие штуки вытворять, блин.
К счастью — если заказчик не понимает таких умных вещей, что типа обследование там и бизнес-процессы, то и схемы бизнес-процессов он от вас не потребует. Поэтому, вы можете ее в явном виде топам заказчика и не предъявлять, исключая риск начала кипучей деятельности. Линейным менеджерам же схему показывать можно и нужно — они крупную реорганизацию затеять не в состоянии.
ДФ>Скорее всего, если иметь навыки сбора требований, аналитики, бизнес-процессов, то классический процесс будет оптимален — тут я не берусь спорить. Но в реальности этих навыков у team-lead зачастую нет и, мне кажется, то, что называют agile методологиями позволяет, за счет роста стоимости проекта, все-таки сделать хоть что-то осмысленное. ДФ>В противном случае вероятность успешного результата (проект удачно внедрен, используется и приносит пользу) очень мала. ДФ>При использовании некоторых техник agile (скорее всего неофициального использования) — есть шансы, что хоть что-то будет хорошо.
Вероятно, да.
ДФ>Собственно, анализируя старый опыт, я понимаю, что там, где я неофициально использовал стандартные техники agile (частые сборки, новые версии выставляемые заказчику, активную работу с заказчиком, приоритеты от заказчика) удавалось сделать хоть что-то. Там, где я делал большие части проекта, понадеявшись на "случайное" ТЗ (хотя по нему и была проведена вполне качественная работа по проектированию, планированию, кодированию) — весь результат пошел в топку.
Случайное ТЗ — понятное дело отстой.
G>>Алгоритм и бизнес-правила согласуются дешевле и быстрее. Для этого полнофункциональный билд излишен. ДФ>Гм. А где-нибудь описана методика согласования бизнес-правил и алгоритмов? Просто по моему опыту есть явная проблема в языках. Формальное описание бизнес-процесса или алгоритма (со всеми условиями) не готов воспринимать заказчик (специалисты в предметной области или конкретные исполнители), а приблизительное описание (которое он может предоставить) обычно дырявое и приводит к некорректным результатам. Картинки не помогают, увы (или я их не умею рисовать — что, в общем, то же самое).
SADT. В книге есть и методика анализа и разработки моделей, и туториал с упражнениями. Эти диаграммы понятны любому идиоту, механическим образом переводятся в связный рассказ на русском языке, но чрезвычайно сложны в составлении с непривычки. Зато если научиться — вы будете нереально круты.
Во-вторых — очень так ничего для описания бизнес-процессов UML Activity диаграмма. Она однозначно проще в составлении, и в чем-то более наглядна, однако с методикой SADT ознакомиться все равно надо, так как там учат не только и не столько нотации, а анализу как таковому. К примеру, вы знаете, что аналитикам запрещено задавать клиенту вопросы, на которые можно ответить "да" или "нет"? Знаете почему? Думаете вы одно, говорите второе, клиент слишыт и понимает третье, и отвечает на вопрос "да". Внимание — на какой вопрос он ответил "да"? Вы не знаете, вы лишены возможности проверить, как он вас понял. А услышав его развернутый ответ, у вас есть шансы это узнать.
Третья вещь, которая поможет в проведении интервью — это мета-модель и милтон-модель НЛП. Раздел, где они учат анализировать и понимать текст, и говорить самому — понятно и непонятно. Пройдя этот тренинг — вы сможете механически, рефлекторно ставить уточняющие вопросы, и устранять ситуации разного толкования одних и тех же слов вами и клиентом. Дополнительный плюс — вас невозможно будет "загрузить" — вы будете прекрасно отличать, когда вам сообщают знание, а когда вешают лапшу. Плюс — вы нужное вам знание по любому вытянете из кого угодно.
ДФ>Собственно, из-за подобных коллизий многие проблемы в алгоритмах и вылезают только в полнофункциональном билде и тестировании на живых данных. ДФ>(Заметим, что предоставить живые данные до запуска многие заказчики отказываются из-за соображений секретности, а сделать корректную модель — тоже не в их силах).
Модель всегда делает аналитик, т.е. вы. Доверять в этом деле нельзя никому, даже себе. Живые документы увидеть весьма желательно, это очень много неясностей с пониманием смысла полей устраняет. Подпишите с заказчиком NDA, вам нужно по одному печатному документу каждого вида. Не так страшно. Или в крайнем случае — работаейте с ними на територии заказчика. Вам надо руками пересчитать значения полей, чтобы совпали цифры — таким образом вы проверяете как вы поняли смысл полей. Фиксируете ваше понимание на бумаге.
G>>А то я не сталкивался с этой проблемой — автоматизация во время реорганизации . Надо взять паузу, чтобы заказчик устаканил свои процессы. Разработку тормознуть, выделить заказчику аналитика. Какой смысл вести разработку постоянно переделывая?
ДФ>Вот, очень важный момент. Если можно выделить аналитика, который может провести реорганизацию — то замечательно. ДФ>Но иногда единственный аналитик — это team-lead группы разработки. И в этом случае процесс реорганизации (скорее — собственно организации) происходит последовательными приближениями софта и людей. Он просто по другому, обычно, не умеет. ДФ>Но очень важно, что бы хоть кто-нибудь в этот момент понял, что происходит фигня и надо остановиться. И далеко не всегда это может быть разработчик — у него может просто не хватить кругозора (и возможности встать в рефлексивную позицию). Да и не учат этому нигде и в книжках по разработке не пишут.
Добивайтесь частой поэтапной оплаты — и тогда нет проблем, можно вести разработку и так. Собственно, предварительный анализ важен только на fixed cost контрактах, если вы будете добиваться оплаты каждой итерации (фактически — почти повеременка получается) — то можно работать как угодно, за бюджет вы вряд ли вылетите.
G>>2 часа на роль — обычно хватало с избытком. Надо знать, что надо спрашивать, и главное — что спрашивать не надо. Вы с менеджерами поменьше говорите, и будет гораздо меньше 8 часов.
ДФ>Угу, в следующий раз попытаюсь поднять предложенную литературу и научиться проводить обследование. Увы, раньше не умел, сейчас работа другого профиля. ДФ>Обидно, что даже не понимал, что не умею ;(
Ок. Почему два часа на роль. Вот приходите вы к тетке, которая, допустим, кассир. Берете у нее ее печатные формы всех документов. Каждый документ фиксирует бизнес-операцию, в которой завязан кассир. Ваша цель на интервью — вычислить scope работы кассира, понять перечень операций, которые она выполняет, из каких действий складывается каждая операция, и записать это на бумаге. Думать в момент интервью не надо — думать в оффлайне будете. В момент интервью вы должны ловить противоречия и недосказанности в речи кассира.
Так вот, более чем на два часа вам никто работника отвлекать скорее всего не даст. Мы обычно закладывали вообще час. Да и мозг за интервью высасывается без остатка. Если анализ покажет, что налицо ахтунг и вы что-то недопоняли (в оффлайне вы будете сопоставлять операции разных людей, с целью выловить более крупные бизнес-операции, в каждой из которых завязана цепочка людей), то придете еще раз на час.
ДФ>>>Обычно, впрочем, не везет и на часть вопросов по алгоритмам или нужным процессам следует ответ "сделайте, там посмотрим, подходит или нет". G>>А вы вопросы задаете по нужным процессам? Ну вы даете. Разумеется, вам так и ответят. Вы должны сами уметь процессы идентифицировать и описывать, в этом работа аналитика и состоит.
ДФ>Гм, я правильно понял, что подтверждение корректности выделенных процессов пользователем не требуется? Я, почему-то, всегда считал, что нужно выделить, описать, а потом — согласовать правильность моего понимания.
Менеджер вам этого не подтвердит — он чаще всего не знает нюансов бизне-процессов, которые делают его исполнители, он знает общую картину. Исполнители же не знают общей картины. После того, как вы построите модель — вы лучше всех в той конторе будете знать бизнес-процесс.
Проверку можно сделать так (допустим, вы ограничиваетесь минимальным изменением бизнес-процесса). Вы быстро-быстро делаете прототип гуя для каждого исполнителя, и показываете каждому из исполнителей его гуй. Уж они вам накомментируют . А вот общую сшивку лучше на своей совести оставлять (или показать линейным менеджерам). Менеджерам вы все равно по первичке любой отчет соберете без проблем — так что к ним визит вежливости и просьба разработать формы отчетов на бумаге или в экселе. С этим — в последнюю очередь, это не держит. Главное — первичка.
Если бизнес-процссы меняются — то лучше ИМХО иметь дело с линейными менеджерами, пусть они проверяют вашу модель бизнес-процессов, и говорят "да". Хотя, тут у каждого свои рецепты. Вообще — даже в случае реогранизации вам все равно нужна модель "как оно есть сейчас". Оптимизацию можно проводить на ее основании с участием линейного менеджмента.
ДФ>По поводу "сделайте — там посмотрим": а какое правильное поведение в тех случаях, когда заказчик должен принять некоторое решение (выбор)? ДФ>(Например, в отделе закупок явно воруют. Предлагается менеджментом насильно внедрить систему автоматического выбора подрядчика, для этого возможно два "книжных" существенно различных подхода (сильно влияющих на проектирование). Я обычно считаю, что выбор должен сделать заказчик. Но часто звучит именно "сделайте, а там посмотрим".)
Либо попросить их утвердить ТЗ (приложением к которому изложить схему), если случай тяжелый — то утвердить легкий прототип ГУЯ, либо договориться на повременную оплату (или ее варианты — скажем, оплата каждой итерации). Любой из вариантов для вас хорош.
G>>Почему не получить? Не понимаю. У меня всегда получалось. И вообще — по моей практике это редкость, по большому счету заказчику все равно, какие будут решения, лишь бы удобно было. ДФ>Уф, завидую. В моей практике есть проекты, задержанные на год, пока топ.менеджер выбирал цвет фона и дизайн отдельных элементов для ПО. Причем согласованные на первом этапе эскизы были проигнорированы (проект внутренний, понятное дело).
Внутренний проект — иногда бывает просто игрушкой для топов. Со всеми вытекающими.
ДФ>Угу, но я долго шел до этого понимания. И, кстати, методики определения "чего ему нужно" до сих пор не знаю. Но зачастую (особенно в "авторитарных" конторах" к целям автоматизации это "что нужно" отношения не имеет...
Дело в том, что система автоматизации вообще слабо зависит от желаний менедмента заказчика. Ее суть в основном определяется фактическими бизнес-процессами. Это костяк системы — подсистема сбора информации и оперативного учета. А вот блок отчетности и аналитики напротив — определяется не столько потебностями сколько пожеланиями. Хорошая новость в том, что его можно хорошо развязать с блоком оперативного учета, чтобы модификации в аналитике и отчетах слабо затрагивали оперативный учет. Другими словами, оперативный учет хорошо делать классикой, а вот отчетность и аналитику — экстремальщиной, постоянно показывая.
Так что на мой взгляд оперативный учет — это всегда "нужно", и ТЗ определяется обследованием. А остальное — по желанию
ДФ>Кстати, а действительно ли это работа аналитика? Зачастую заказчику нужно увеличить, например, обороты — и для этого он, зачем-то, заказывает веб-сайт или CRM. До заключения контракта еще можно объяснить, что для этой цели нужно нечто совсем другое. Но если заказ уже спущен — то любая деятельность не приведет к результату. Есть разумное поведение в этих случаях?
Есть. Если ваша работа — разработка сайта, то вы должны делать ему сайт, а не решать глобальные проблемы. Если заказчик думает, что это увеличит ему оборот — то это его проблемы. Он над ними подумал, и пришел к неверному выводу, но вам платит за сайт. Зачем ему объяснять, что сайт ему не нужен? Вам деньги и работа не нужна? Не пойму. Ваше разумное поведение — сделать заказчику хороший сайт, и ненавязчиво прорекламировать услуги смежников (за откаты или каким другим разумным образом) или свои собственные по его раскрутке.
Здравствуйте, Alex EXO, Вы писали:
AE>Здравствуйте, Gaperton, Вы писали: G>>Вы описываете реальную жизненную ситуацию. В которой новые бизнес-процессы должны быть зафиксированы на бумаге, и пройти серию проверок. Этого глупо не делать. Это в данном случае есть работа аналитиков и консультантов.
AE>+1 согласен AE>Но при этом не забываем, что пока эти БП таки пока остаются "сферическим конем в вакууме". Даже после всех проверок.
Ну допустим. Хотя можно довольно неплохо выверить их и на бумаге, выловив процентов 80 проблем, а то и больше.
G>> Никаких agile в такой ситуации, категорически.
AE>agile работает несколько на другом уровне — нарезке на минимально осмысленные изменения. Включаяя и изменеия БП и поддерживающую разработку. "Опасные шаги" нужно сделать как можно мельче. А уж как это назвать — второй вопрос.
Предположим. Мне казалось, что agile относится только к разработке? Не могли бы вы сказать конкретно и по возможности математически точно — каким именно образом это реализует agile?
G>> Именно будет завершенным именно НИР. И одним из результатов НИР будет проект ТЗ и пожтапный план внедрения.
AE>Да. Почти так. AE>Этап 1. Описание БП. На _весь_ комплект взаимосвязанных БП. AE>Этап 2. Поэтапный план внедрения.
AE>а вот дальше цикл: AE>3.1 ТЗ этапа AE>3.2 разработка блока ИС поддерживающего функционал этапа AE>3.3 тестипрование AE>3.4 _опа_! "Внимание прыгаем". Изменеие БП в организации, запуск блока ИС AE>3.5 опытная эксплуатация — нестабильный этап(кошмар и аврал, выворачивание всего блока на изнанку) AE>3.6 опытная эксплуатация — стабилизация, документирование итогового функционала, написание "журнала различий" (какие требования менялись и почему — понадобится на шаге 3.1 следующих этапов) AE>3.7 рефакторинг блока (причесывание того кода, который аврально менялся на этапе 3.5) под непрерывным тестированием. AE>3.8 "рефакторинг" общего описания комплекта БП (с шага 1)
AE>Самым дорогим для всех здесь является шаг 3.5 AE>И полностью исключить его обычно не удается. Лучше всего работает сокращение всего "цикла 3.*"
Ай-ай. Проватерфолили вы, Алекс, одину ватерфольную проверку, которая вам сильно облегчила бы жизнь. Легковесные прототипы гуя для исполнителей, которые идут между началом разработки и завершением работ по постановке ТЗ. Как раз посерединке. Служат они для верификации того, как вы переносите бизнес-процессы в ТЗ (реализуете их), и для вылова остатков ошибок в самих БП. И тогда не будет "_ОПА_" на 3.4, будет маленькое "опаньки". Да, хорошо, если вы используете РАД-тул, который позволит вам не выкинуть эти прототипы. Это вполне возможно.
Это раз. Два. Я бы поправил ваш план, он на мой взгляд не очень хорош. И главной целью первого этапа поставил скорейшее выделение функицональных блоков, которые можно пускать независимо и/или последовательно, а также зависимостей между ними и их приоритетов. Результат первого этапа — общая грубая схема (декомпозиция) БП + поэтапный план дальнейших работ (в том числе и по уточнению БП). После чего, половину работ вашего этапа 1 (по детальному уточнению и верификации БП, включая изготовление легковесных прототипов ГУЯ) я бы перенес в рамки Этапа 2, и вел бы их также последовательно по функцинальным блокам, с конвейерным наложением друг на друга. То есть, полномасштабная разработка стартует по закрытию фазы с легкими прототипами, после чего группа "аналитиков" берет следующий функциональный блок.
Три. То что я вам сейчас сказал в "раз" и "два" — это ватерфол, мать его, построенный по всем ватерфольным канонам. И он — ацки хорош и разумен. Am I wrong?!
G>> Кстати, для большой организации практически всегда можно запускать автоматизацию потапно. Без исключений. Вы неправы, Алекс, утверждая, что надо реализовать обязательно полную функциональность. Просто этапы надо бить не по отделам и филиалам, а по "функциональным блокам".
AE>Да. Именно так. AE>Но только такой "функциональный блок" — это не макет. На него сразу падает полная нагрузка (в смысле числа пользователей и информационного потока).
Разумеется. Макет — это макет гуя, я про них написал выше.
G>>В описываемом вами случае внедрение КИС является частью более крупной работы по реорганизации БП, и общую работу надо строить не по канонам разработки софта. Вот и весь фокус. Софт — это необходимый, но далеко не главный этап.
AE>Только софт тоже нужно разрабатывать. И вот получающаяся в итоге разработка софта ("проектция" "общей работы" на плоскость разработки софта) очень сильно напоминает agile.
По мне — так самый что не на есть ватерфол, даже не в профиль. Разумеется, после добавления процедур контроля качества, отсутствующие у вас — у вас при вашем плане ошибки в БП и их реализации в постановке на поздний этап пролезают, а им правильнее выставить еще один барьер.
> Ок. Почему два часа на роль. Вот приходите вы к тетке, которая, допустим, кассир. Берете у нее ее печатные формы всех документов. Каждый документ фиксирует бизнес-операцию, в которой завязан кассир. Ваша цель на интервью — вычислить scope работы кассира, понять перечень операций, которые она выполняет, из каких действий складывается каждая операция, и записать это на бумаге. Думать в момент интервью не надо — думать в оффлайне будете. В момент интервью вы должны ловить противоречия и недосказанности в речи кассира.
Ну прямо как дети. Какие два часа? На кассира — 5 минут. Больше — значит студент или не тем делом занят.
Здравствуйте, grosborn, Вы писали:
>> Ок. Почему два часа на роль. Вот приходите вы к тетке, которая, допустим, кассир. Берете у нее ее печатные формы всех документов. Каждый документ фиксирует бизнес-операцию, в которой завязан кассир. Ваша цель на интервью — вычислить scope работы кассира, понять перечень операций, которые она выполняет, из каких действий складывается каждая операция, и записать это на бумаге. Думать в момент интервью не надо — думать в оффлайне будете. В момент интервью вы должны ловить противоречия и недосказанности в речи кассира.
G>Ну прямо как дети. Какие два часа? На кассира — 5 минут. Больше — значит студент или не тем делом занят.
Ну да, на кассира реально уходило минут 5-10 . Правда . У кассира все операции типовые, там мало чего накрутить можно .
Вообще — если знать типовую организацию торговой компании — все гораздо проще идет. И встреча с кассиром не страшна.
> G>Ну прямо как дети. Какие два часа? На кассира — 5 минут. Больше — значит студент или не тем делом занят. > > Ну да, на кассира реально уходило минут 5-10 . Правда . У кассира все операции типовые, там мало чего накрутить можно . > > Вообще — если знать типовую организацию торговой компании — все гораздо проще идет. И встреча с кассиром не страшна.
Ага, ну тогда ты должен понимать, что пример с кассиром, как бы это сказать, крайне неудачен, поскольку описывать БП кассира, это всё-равно, что якорь точить. Давай жизненный пример
>> G>Ну прямо как дети. Какие два часа? На кассира — 5 минут. Больше — значит студент или не тем делом занят. >> >> Ну да, на кассира реально уходило минут 5-10 . Правда . У кассира все операции типовые, там мало чего накрутить можно . >> >> Вообще — если знать типовую организацию торговой компании — все гораздо проще идет. И встреча с кассиром не страшна.
G>Ага, ну тогда ты должен понимать, что пример с кассиром, как бы это сказать, крайне неудачен, поскольку описывать БП кассира, это всё-равно, что якорь точить. Давай жизненный пример
Знаешь, мне тут утверждали что уходит по 8 часов на роль, и пример с кассиром я привел как самый тупой и гарантированно знакомый. Час — это в среднем на человека закладывается при планировании общего времени интервью, средняя температура по больнице. Бывает больше-меньше в обе стороны.
Реальный пример — час — это например тетка выписывающая счета, накладные, и выполняющая резервирование товара, первое звено при оптовой закупке товара. Там время основное уходит на то, чтобы нечто связное из тетки вытащить, она ведь зараза путается в показаниях и забывает важные исключения из правил, в которых вся тема. Один раз я с такой теткой два часа беседовал в одной конторе которая торгует сумками. Случай был тяжелый.
Другой реальный пример — тоже оптовая торговля, где первым звеном офомления + поиском заказов занят менеджер по продажам. Они вели клиента от и до — и делали дохрена. Там была такая проблема — их было пятеро, и с каждым из них были свои, индивидуальные и секретные договоренности по схеме рассчета процентов. И они были разные. И изменять их было нельзя. Засада полная (т.е. бардак). Несмотря на общий, казалось бы, процесс, — интервью с каждым менеджером индивидуально (в среднем — час на человека, с менеджером менеджеров — два часа), упорядочивание схем начисления процентов, сверка схемы с данными главного менеджера, выработка политики, обобщающей все индивидуальные договоренности.
Сложнее всего когда полный бардак в конторе. Этого больше всего не люблю. Тогда может вылезти поболе часа на исполнителя, с учетом большого количества разных подходов. Тогда по ходу автоматизации приходится его ликвидировать — т.е. "реорганизацию БП" провести приходится, иначе заказ не выполнить. И гарантировано — за это платить не будут ("бизнес-процесс" слишком умное слово для таки компаний). Но это было распространенно до 2000 года. Сейчас — не знаю, наверное етественным отбором такие конторы должны были поуменшиться в количестве. Мой опыт по анализу БП заканчивается 2000 годом, если не считать помощи друзьям и знакомым. Тогда я как решал — либо идти в полноценные бизнес-аналитики на фулл-тайм, занявшись реорганизацией БП и консалтингом профессионально, или в хардкорную разработку — хотелось на крупных заказах или в крупной девелоперской конторе поработать, где порядок, чтоб хоть посмотреть на него, какой он. Ушел в результате в разработку.
>Мой опыт по анализу БП заканчивается 2000 годом, если не считать помощи друзьям и знакомым. Тогда я как решал — либо идти в полноценные бизнес-аналитики на фулл-тайм, занявшись реорганизацией БП и консалтингом профессионально, или в хардкорную разработку — хотелось на крупных заказах или в крупной девелоперской конторе поработать, где порядок, чтоб хоть посмотреть на него, какой он. Ушел в результате в разработку.
Тогда я тебя просто дополню, поскольку этим анализом мне приходится заниматься по сю пору: адекватных норм на опрос нет вообще. Опрос таких рабочих мест, как менеджер продаж, кассир, бухгалтер, там я не знаю секретарь, кладовщик и т.п. Заключается только в том, что бы задать пару-тройку вопросов типа "а это у вас есть?" "а так вы делаете?" "а таким образом вы сможете работать?". Поскольку эти роли типовые и тому, кто делает опрос надо бы предварительно почитать их должностные инструкции, учебники по управлению и бухучету, ну в общем знать что они делают заранее. Кстати, тут мы затрагиваем одну из самых больших проблем в ПМ — повторное использование кода, методологий, опыта. Как я понял, этого в ПМ нет в принципе. Нет разнообразия решаемых задач, всё это есть разнообразие тех глупостей, которые мы совершаем при решении одних и тех же задач (c). Отвлекся. Так вот об опросах: это рулетка, знаком опросчик с проблемной областью или нет. Если не знаком, за час он выдаст неадекватный результат. Если знаком, ему 5-10 минут хватит. Соответственно эта стадия считается не по нормам.
Здравствуйте, Gaperton, Вы писали:
G> Тогда я как решал — либо идти в полноценные бизнес-аналитики на фулл-тайм, занявшись реорганизацией БП и консалтингом профессионально, или в хардкорную разработку — хотелось на крупных заказах или в крупной девелоперской конторе поработать, где порядок, чтоб хоть посмотреть на него, какой он. Ушел в результате в разработку.
А можно вопрос? Ну и как нашелся порядок? Я серьезно, просто у меня такое впечатление, что порядка нигде нет в разработке.
Вот недавно опять после хорошего обсуждения договорились сформулировать требования для одной фичи, выделили ответственного чтобы он это сделал, а в результате для разработки мне пришло 3 разных варианта (один от этого человека и парочка от руководства) Фичка конечно маленькая, это я так, для примера... Большие вещи мы все-таки стараемся специфицировать более внятно. Да и я уже умею минимизировать подобные проблемы
Но судя по общению с окружающими, большинство компаний софрверных в России под менеджментом требований подразумевает наличие какого-либо документа который хоть как-то описывает что надо сделать и самое главное, что его конечно никто не синхронизирует с действительностью
Здравствуйте, grosborn, Вы писали:
>>Мой опыт по анализу БП заканчивается 2000 годом, если не считать помощи друзьям и знакомым. Тогда я как решал — либо идти в полноценные бизнес-аналитики на фулл-тайм, занявшись реорганизацией БП и консалтингом профессионально, или в хардкорную разработку — хотелось на крупных заказах или в крупной девелоперской конторе поработать, где порядок, чтоб хоть посмотреть на него, какой он. Ушел в результате в разработку.
G>Тогда я тебя просто дополню, поскольку этим анализом мне приходится заниматься по сю пору: адекватных норм на опрос нет вообще. Опрос таких рабочих мест, как менеджер продаж, кассир, бухгалтер, там я не знаю секретарь, кладовщик и т.п. Заключается только в том, что бы задать пару-тройку вопросов типа "а это у вас есть?" "а так вы делаете?" "а таким образом вы сможете работать?". Поскольку эти роли типовые и тому, кто делает опрос надо бы предварительно почитать их должностные инструкции, учебники по управлению и бухучету, ну в общем знать что они делают заранее.
Ну, пожалуй я все-таки вяло не вполне соглашусь. А именно — вы не можете рассчитывать на то, что все пойдет так гладко, и за пять минут, даже если знаете типовые процессы. Дьявол в деталях, во-первых. Оперативный учет варьируется от виду деятельности компании, где типовые процессы разные, во-вторых, а их знать все тяжело, это с опытом приходит. Оперативный учет зависит от грамотности и фантазии менеджмента — в третьих, так как часто велосипеды изобретают.
Разумеется, знание типовых процессов помогает. Для кассира и бухгалера все более-менее одинаково. Да и то не совсем. В бухучета, который мы решали тупо — установкой 1С, довольно часто — в половине случаев, требуется докрутка. Дело в том, что в обязанности главбуха входит разработка плана счетов и типовых схем проводок. И в половине случаев приходится допиливать бухгалтерию, меняя планы счетов, меняя схемы проведения первички, и добавляя новые документы.
Кроме того. Бухгалтерию можно интегрировать в оперативный учет, сделав автоматическую или полуавтоматическую генерацию проводок (обыкновенно, это делается вручную — и бухгалтерия фактически интегрирована в бизнес-процессы). Для этого, с бухгалтером придется говорить дольше, как и с остальными участниками.
Касательно инструкций, во-первых, должностных инструкций может просто не быть. Во-вторых, даже если они есть — им нельзя доверять, часто они пишутся как бог на душу положит, и не поддерживаются в актуальном состоянии. В третьих — роли действительно типовые, и знание типовых процессов критично для аналитика, но фактические обязанности могут отличаться от компании к компании. Одно дело, когда речь идет о бухгалетрских документах и учете — тут все более-менее у всех одинаково. А вот схемы резервирования, и оперативный учет могут различаться. Лучше проверить.
G>Кстати, тут мы затрагиваем одну из самых больших проблем в ПМ — повторное использование кода, методологий, опыта. Как я понял, этого в ПМ нет в принципе. Нет разнообразия решаемых задач, всё это есть разнообразие тех глупостей, которые мы совершаем при решении одних и тех же задач (c). Отвлекся. Так вот об опросах: это рулетка, знаком опросчик с проблемной областью или нет. Если не знаком, за час он выдаст неадекватный результат. Если знаком, ему 5-10 минут хватит. Соответственно эта стадия считается не по нормам.
А если в этой компании не знакомы с типовыми процессами, и выдумали свой велосипед? Что тогда насчет 5-10 минут? Как у меня было в Стенторе, например — клинический случай. Товар у них "на главный виртуальный склад" поступал, а роль счета с накладной (и чего-то еще, не помню) в оперативном учете выполнял документ "спецификация". Плюс тетки тупые, которые внятно на поставленный вопрос ответить не могут, не умеют главное от второстепенного отделять, тянуть из них надо все клещами? И это была самая обычная оптовая торговля (вернее, под реализацию они в магазины товар давали — тоже по своей, дико странной схеме).
Короче, чтобы в 5-10 минут уложиться, надо мегагуру быть с как минимум 10 лет опытом и знанием всех кривых вариантов бизнес-процессов во всех кривых позах.
> Короче, чтобы в 5-10 минут уложиться, надо мегагуру быть с как минимум 10 лет опытом и знанием всех кривых вариантов бизнес-процессов во всех кривых позах.
Не веришь? Ну и пусть, не буду спорить, пилите Шура, пилите...
Только вот я конечно дико извиняюсь, но остаюсь при мнении, что это, ну, в общем, глупость, снова делать одну и ту же работу (изучать БП кассира на натуре), которую до нас уже сделали тысячу раз, и ещё молодых учить делать так же. Остаюсь при мнении, что бы учиться по учебникам не нужно быть мегакенгуру.
Здравствуйте, Gaperton, Вы писали:
G>Короче, чтобы в 5-10 минут уложиться, надо мегагуру быть с как минимум 10 лет опытом и знанием всех кривых вариантов бизнес-процессов во всех кривых позах.
Мне кажется, одного опыта мало, ограниченность человека и развитие процессов позволяют очень большим фирмам достаточно долго разрабатывать, знакомые всем нам программные продукты.
Здравствуйте, grosborn, Вы писали:
>> Короче, чтобы в 5-10 минут уложиться, надо мегагуру быть с как минимум 10 лет опытом и знанием всех кривых вариантов бизнес-процессов во всех кривых позах.
G>Не веришь? Ну и пусть, не буду спорить, пилите Шура, пилите... G>Только вот я конечно дико извиняюсь, но остаюсь при мнении, что это, ну, в общем, глупость, снова делать одну и ту же работу (изучать БП кассира на натуре), которую до нас уже сделали тысячу раз, и ещё молодых учить делать так же. Остаюсь при мнении, что бы учиться по учебникам не нужно быть мегакенгуру.
Слушай, про кассира реально верю, и более того — не могу припомнить у себя ситуации, когда я после визита к кассиру не задавался бы вопросом — зачем я вообще к нему приходил . И с тем, что учиться по учебникам надо — на 100% согласен. А вот про бухгалтера — точно знаю, что перетереть с ним насчет интеграции или хотя бы импорта проводок придется. Они такие выдумщики бывают на самом деле, эти бухгалтера.
И взять даже казалось бы типовые схемы работы торговых предприятий — если они дают товар под реализацию — то они тоже могут оказаться редкостными выдумщиками. При оптовой торговле — может различаться от компании к компании процесс отгрузки. Может также быть нестандартной схема учета затрат при рассчете себестоимости в оперативном учете — это не смотря на то, что есть FIFO, LIFO и средневзвешенная. Скажем, если мы торгуем товаром со сроком годности — в аптеке, например, там может применяться экзотическая версия LIFO. Может отличаться схема резервирования и закупки товаров — они бывают экзотическими. Есть в природе дикие гибриды кредитных схем и схем под реализацию.
Откуда вам знать, что за фасадом знакомых слов не кроются нестандартные выдумки? Я вот страховался и всегда восстанавливал фактический процесс. Если клиент делает вам почасовую оплату — он не поймет, почему должен за переделку платить. Нервничать начинает. Лохом консультанта считать.
Здравствуйте, vpedak, Вы писали:
V>Здравствуйте, Gaperton, Вы писали:
G>> Тогда я как решал — либо идти в полноценные бизнес-аналитики на фулл-тайм, занявшись реорганизацией БП и консалтингом профессионально, или в хардкорную разработку — хотелось на крупных заказах или в крупной девелоперской конторе поработать, где порядок, чтоб хоть посмотреть на него, какой он. Ушел в результате в разработку.
V>А можно вопрос? Ну и как нашелся порядок? Я серьезно, просто у меня такое впечатление, что порядка нигде нет в разработке.
Гхм. С ним ведь, с порядком оказалось как. Думаешь по ходу дела, что бардак, а потом вспоминаешь через несколько лет — и доходит — так то ж порядок был, блин . Я серьезно, именно так .
V>Вот недавно опять после хорошего обсуждения договорились сформулировать требования для одной фичи, выделили ответственного чтобы он это сделал, а в результате для разработки мне пришло 3 разных варианта (один от этого человека и парочка от руководства) Фичка конечно маленькая, это я так, для примера... Большие вещи мы все-таки стараемся специфицировать более внятно. Да и я уже умею минимизировать подобные проблемы
Хо-хо. Это управление требованиями, с этим я еще порядка своими глазами не видал. Очень хочу. Природа порядка здесь — требования должны быть трассируемы. Другими словами, вы должны иметь возможность для каждой фичи установить причину ее появления, и ее критичность, что позволит вам управлять ее приоритетом по ходу проекта. Если эта связь отслеживается документально — все хорошо. Если после согласования требований при начале разработки никто уже не помнит, откуда фича взялась, и чем продиктована необходимость в ней — вы лишены возможности сделать репланнинг по ходу проекта, чтобы уложить его в сроки.
И вот еще какой момент. Если вы не понимаете, как это устроить нормальным человеческим образом — на пальцах, в уме, или простых текстовых документах, то и тулзы управления требованиями вам не помогут.
Мы для начала разработали новые формы проектных документов (пара недель назад), по которым реально проследить трассировку. Что позволяет выполнять формальные инспекции — и вылавливать ошибки в технических требованиях, переходу к ним от маркетинговых, и переходе от техтребований к реализации до старта самой реализации. Формы просты в заполнении, и допускают кросспроверки на полноту, непротиворечивость, и соответствие. Вот такое видение порядка. Посмотрим, как будет работать.
Первые результаты уже есть — при изменении формы документа в одном из текущих проектов на новую мы серьезно уточнили технические требования, и доказали их соответствие сценариям применения. После чего — отправили на повторную проверку (предыдущие требования уже успешно прошли проверку), и повторная проверка показала огромную кучу неточностей в сценариях, и как следствие — пробелы в техтребованиях (аукнулось бы стрессовой ситуацией на кодровании — мы бы их нашли позже, в середине проекта, и перепугались бы). Это сильно расстроило автора документа — он сказал так: "почему так много замечаний — ведь это лучшее и самое понятное ТЗ, которое мы когда либо делали — неужели документу стало от этого хуже?!". А ему ответили: "Вот, именно потому, что документ стал лучше, мы и смогли за столь короткое время найти в нем так много ошибок — они теперь стали как на ладони!"
V>Но судя по общению с окружающими, большинство компаний софрверных в России под менеджментом требований подразумевает наличие какого-либо документа который хоть как-то описывает что надо сделать и самое главное, что его конечно никто не синхронизирует с действительностью
Ну, одно только наличие документов — это разумеется не порядок. Это то, что в этой конфе все называют "ватерфолом". Типа, пишешь документы — вотерфолишь значит потихоньку. На самом деле суть вотерфола в другом — он основан на посылке, что раннее обнаружение ошибок удешевляет разработку. Для этого документы и пишут — чтобы их проверкой можно было найти ошибки тогда, когда кода еще нет. Во многих ли конторах практикуют формальные инспекции документов? То-то же. Нафига их писать, если их не проверять. Эдак их дешевле вообще не писать — результат тот же.
А говорят — вотерфол, вотерфол во всем виноват. Уметь надо вотерфолить, это ж не на броневик взбираться, как в XP. И не лобовая кавалерийская атака первой конной со сверкающими отточенными шашками наголо, как в agile. Истинный вотерфол — это вдумчивое стратегическое планирование, напряженная штабная работа, шуршание карт, тихие переговоры насупленных офицеров и генералов, математически выверенный дебют, гамбит, и эндшпиль. Это эшелонированная оборона и молниеносные десанты, прорывы танковыми клиньями с флангов и заходом противнику в тыл! Вот каков истинный вотерфол — он нетороплив, как падающий осенний лист, и внезапен, как удар весеннего грома. Выдержка — оборотная сторона решительности. Хао. Я все сказал.
> Слушай, про кассира реально верю, и более того — не могу припомнить у себя ситуации, когда я после визита к кассиру не задавался бы вопросом — зачем я вообще к нему приходил . И с тем, что учиться по учебникам надо — на 100% согласен. А вот про бухгалтера — точно знаю, что перетереть с ним насчет интеграции или хотя бы импорта проводок придется. Они такие выдумщики бывают на самом деле, эти бухгалтера.
Когда разберешься с этими выдумщиками поближе, выясняется, что выдумывают они тогда, когда не знают, как сделать правильно.
К сожалению, в ближайшее время не смогу ответить развернуто, на своих примерах. Пиковая нагрузка. Но если ты приведешь конкретный пример, совсем не нужно его подробно описывать, просто укажи суть, я тебе скажу где там ошибка. Пример с приходованием на виртуальный склад не понятен, поскольку ты не указал, зачем они так сделали. Могу предположить, что с компьютером умела работать только одна тетка, и могла оприходовать только на один склад
Здравствуйте, grosborn, Вы писали:
>> Слушай, про кассира реально верю, и более того — не могу припомнить у себя ситуации, когда я после визита к кассиру не задавался бы вопросом — зачем я вообще к нему приходил . И с тем, что учиться по учебникам надо — на 100% согласен. А вот про бухгалтера — точно знаю, что перетереть с ним насчет интеграции или хотя бы импорта проводок придется. Они такие выдумщики бывают на самом деле, эти бухгалтера.
G>Когда разберешься с этими выдумщиками поближе, выясняется, что выдумывают они тогда, когда не знают, как сделать правильно.
Да, ты абсолютно прав. Но от этого не легче. У тебя выбор — объяснять им, как надо делать правильно (для чего надо полюбому разобраться, кстати), или сделать как у них сейчас, чтобы они были довольны. Так как мне платили деньги не за business process reengineering, а за разработку и внедрение специального софта, заточенного под их, пусть кривые, но бизнес-процессы, я выбирал второй вариант. Вопрос в том, за что тебе платят деньги. Если за то, что ты им говоришь "как правильно" — это одно. Если за разработку и внедрение системы — то предполагается, что ты под них подстраиваешься, а не наоборот.
Насчет того, как сделать правильно и бухгалтеров. Главбух вообще-то обязан разработать план счетов для своей компании и схемы проводок первички. Так вот, чем лучше бухгалтер, тем в большую сторону эти вещи будут отличаться от типового плана счетов и типовых проводок. Бухгалтер может вести аналитику по счетам, чтобы получать детальные отчеты, например. Что в типовом плане счетов не прописано. Бухгалтер может оптимизировать схемы проводок. Разумеется, для того всего нужны мозги и понимание бухучета. А типовая схема в учебнике написана, так любой делать может.
Далее. АСУ, с позволения сказать, бухучета, позволяет генерировать проводки автоматически по первичке. "Правильно", по книгам — это далать надо вручную. Коль скоро схемы проводок и планы счетов отличаются от организации к организации, а также оличается и их хозяйственная деятельность — то в общем случае будут отличаться и операции и проводки. В простых случаях — могут измениться счета и субсчета с аналитикой, в более сложных — появятся новые "документы", вообще не имеющие прямого эквивалента в бумажном виде, которые будут генерировать пачки проводок.
По хорошему — надо всегда оперативный учет связывать с бухгалтерским автоматически или полуавтоматически. Вот например, в "золотых страницах" счета-фактуры выписывала бухгалтерия, а не "менеджеры по продажам" — специфика бизнеса такая, на то была причина, изменять это было дорого и сложно — налетели бы на реорганизацию, что сорвало бы нам наш заказ. Имеем — бухгалтерия завязана в процесс продаж, и геморройный был этот процесс, надо сказать. Что сделали — прозрачным образом интегрировали 1Сv7.7 в систему оперативного учета на базе MS SQL + VB (не фокус ни разу — COM рулез форева). Клиент сохранил свой бизнес-процесс, что радикально удешевило внедрение системы, плюс — избавился от геморроя, вызванного этим процессом. Клиент счастлив, считает нас волшебниками. Получилось так именно потому, что мы не учили клиента жить. Мы даем ему то, что он хочет.
G>К сожалению, в ближайшее время не смогу ответить развернуто, на своих примерах. Пиковая нагрузка. Но если ты приведешь конкретный пример, совсем не нужно его подробно описывать, просто укажи суть, я тебе скажу где там ошибка.
Это не интересно, где там ошибка . Кстати, есть популярные схемы, на которых просто нет стандарта, как делать правильно, и поэтому у всех кто во что горазд. Например, продажа и покупка "под реализацию", что не кредит, и не предоплата — товар юридически остается в собственности оптовой компании до момента продажи. А посему, никакими правилами это не регламентируется — это лежит за рамками бухучета, клиент товар на забалансовый счет принимает. Так очень часто работают оптовые торговые компании с розничными магазинами. Менять эту схему, если она крива, они с твих слов не будут. А если начнут — это удлиннит тебе период, через который ты получишь свои деньги, только и всего. То есть пользы от того, что ты им покажешь, где ошибка, для тебя не будет никакой.
G>Пример с приходованием на виртуальный склад не понятен, поскольку ты не указал, зачем они так сделали. Могу предположить, что с компьютером умела работать только одна тетка, и могла оприходовать только на один склад
Здравствуйте, Gaperton, Вы писали: G>Ай-ай. Проватерфолили вы, Алекс, одину ватерфольную проверку, которая вам сильно облегчила бы жизнь. Легковесные прототипы гуя для исполнителей, которые идут между началом разработки и завершением работ по постановке ТЗ. Как раз посерединке.
Согласен. Подумаю что тут можно сделать.
(Порою могут быть проблемы, если этапы 1,2 делает другая организация — "консультанты по реинжинирингу".)
Гап, ты мысли рожаешь просто на лету. Это хорошо, что ты методолог по учебнику, а то бы ты так накуролесил со своей фантазией!
Первое, про русский язык.
Я когда-то кодил годик на низком уровне. Хелпов на русском тогда сосем не было. За тот год я разучился по русски ясно выражаться, всё порывался на хорошем еврейско-английском ответить. Хелпы видишь ли израильтяне писали. Потом пришлось специально восстанавливать русский.
Ты это, аскера не бей, может он суперкодер?
Дальше, в ответ на твои вышеизложенные соображения:
Ты вроде бы и прав, но это по состоянию на 5 лет назад. Не знаю, или я так продвинулся, или ты остался в 2000 году, но сейчас методики такие, что типовые р.м. обследовать почти не нужно. Менеджер продаж, это тоже типовое р.м. Варианто мало. И работа по типовым р.м. заключается не в том, что бы дописать для них их дурдом, а подобрать вариант готового решения или решения на стадии разработки. Ты полгода будешь свое решение отлаживать, а через полгода тебе придется краснеть, когда всё это на свалку и какой-нибудь старпер будет ставить то, в чем он ни уха ни рыла, а ведь король положения.
Это я про типовые р.м., подходы и методики.
Дальше, как я начинаю понимать, наш спор вырос из пустого места, из разницы оценок. Ты обработку обмена 1С и VB считаешь проектной работой, а я считаю это разовой работой, которая выполняется без всякого водопада, на раз. Ты проводки бухгалтера считаешь страшным делом, а считаю, что на 99.9% всё везде одинаково, а где неодинаково я конечно видел, но за этот маразм простите, убивать нужно.
Третье, пока ты не признаешь, что во всех этих ПМ-ах дефект, не позволяющий им накапливать и переиспользовать знания, я тебя уважать не буду
Здравствуйте, A.Lokotkov, Вы писали:
AL>Здравствуйте, Gaperton, Вы писали:
G>>... Истинный вотерфол — это ... математически выверенный дебют, гамбит, и эндшпиль.
AL>Видимо, миттельшпиль, а не гамбит Чего там гамбитить то?
Скорее, да Но можно, наверно, и погамбитить, при желании-то
DM>>Для вотерфольных моделей, и многих итерационных цели две: DM>>1) создать программу DM>>2) написать документацию DM>>Получается вместо одного продукта делается ДВА! _>О боже. Как Вы собираетесь поддерживать проект, не имея документации? Или у SCRUM-мастеров так принято — наследил и убежал, а после меня хоть трава не расти?
Не поверишь, а ведь получается. Достаточно обходиться зарисовками и фотками доски.
А в тех проектах, где была обширная документация — всегда тормоза разработки неслыханные.
За документацию руководство для пользователя не считается
DM>>В гибких методологиях, особенно SCRUM та же ерунда. Только пункт второй вычёркивается и добавляется ещё один DM>>1) создать программу DM>>2) (ВЫЧЕРКНУТЬ) написать документацию DM>>3) создать самоорганизующуюся Команду _>Товарищ, я Вас не вполне понимаю. Вы предлагаете на каждый проект заново команду создавать?
Тебе нужен ответ?
Народ, чеслово, такое ощущение, что я разговариваю с теоретиками из мира разработки.
Кто нить вообще работает? Создаёт ПО? Не проектирует, не анализирует, не брэйнстормит. А просто поговорил и сразу чик-чик по клаве в редакторе — чтобы потом нажать компиляция и вышло ПО, а не груда супер важной документации, которую никто кроме автора не читает :D
DM>А в тех проектах, где была обширная документация — всегда тормоза разработки неслыханные.
Ты софт также быстро разрабатываешь, как отвечаешь на сообщения?
Здравствуйте, VGn, Вы писали:
DM>>А в тех проектах, где была обширная документация — всегда тормоза разработки неслыханные. VGn>Ты софт также быстро разрабатываешь, как отвечаешь на сообщения?
Дык отвечать на сообщения — это ж считай тож самое, что обширную документацию писать. Вот и тормоза неслыханные налицо! Денис молодец, хорошо работает над обоснованиями своих тезисов
. Внутренний заказчик не является специалистом ни в сборе и формулировке требований, ни в их анализе. Вы же предполагаете, что полные и непротиворечивые требования должны появиться как-то сами собой. Естественно, этого не происходит.
.
