Здравствуйте, 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 лет опытом и знанием всех кривых вариантов бизнес-процессов во всех кривых позах.
У вас, конечно, у заказчика понятно что нет.
Я как менеджер в такой ситуации настоял бы на документировании планируемых бизнес-процессов и серии формалных инспекций, с целью выловить максимум ошибок на ранних этапах. Т.е. заставил бы работать так, как это делают профессионалы по реинжинирингу бизнес-процессов. Никаких agile в такой ситуации, категорически.
.
