Как собрать исчерпывающие бизнес-функциональные требования в начале проекта внедрения?

29.08.18

Программная инженерия - Работа с требованиями

В этой статье я расскажу, как гибкие и классические подходы к управлению проектами предлагают обходиться с требованиями заказчика. А заодно поделюсь опытом руководителей проектов, за счет чего можно убедить заказчиков работать по методологии Agile, и когда это невозможно.

Честно скажу, название статьи навеяно старым анекдотом… 

Как заставить себя вставать пораньше? Как просыпаться выспавшимся? Как приходить на работу радостным? Как уехать из Крайнего Севера и жить в Сочи? Как есть всё подряд и не толстеть? Обо всем этом читайте в новой книге "Никак, б*”%#*!"  "Никак, б*”%#*!" - теперь и в твердом переплете.

Дисклеймер. Я ни секунды не утверждаю, что именно вам нужно срочно переходить с Водопада на Agile. Универсальной и идеальной методологии вообще не существует. Я ни секунды не утверждаю, что в вашем случае возможен переход на Agile, а мешающие этому проблемы преодолимы. Я просто констатирую, что у многих компаний есть успешный опыт руководства ИТ-проектами при помощи гибких методологий, и этот опыт может оказаться полезным.

Управление требованиями: больная тема

Начну, с вашего позволения, с небольшого списка литературы.

Я уже рассказывала, какие бывают подходы в управлении проектами. Чтобы у нас была возможность говорить на одном языке, рекомендую перед прочтением этой статьи ознакомиться с моими материалами на эту же тему Можно ли объять необъятное или чем Agile отличается от водопада? и Почему Agile превращается в Тяп-ляп. Кто виноват и что делать?  Тема написания ТЗ и уточнения требований была в свое время частично раскрыта в статье Александра Чавалаха Разработка технического задания. Что это такое, зачем оно нужно, с чего начать и как должно выглядеть?  Классические подходы (водопад/итеративный подход) разбирает в своих статьях Иван Селиховкин, так что не буду его дублировать, и поговорю подробнее про применение гибких методов в управлении. 

Опрос среди руководителей проектов внедрения 1С, проведенный на сайте Инфостарт, показал, что из всех проблем лидируют “Изменение требований в ходе проекта” (около 25% опрошенных) и “Нечеткие требования заказчика” (около 24% опрошенных).

 

Проблемы при внедрении проектов

Итак, в чем ключевая особенность управления по Agile в вопросах создания ТЗ и управления требованиями?.. Очень просто - ограничения не фиксируются в начале проекта. То есть у нас нет той самой “скорлупы яйца” - жестких сроков-бюджета-содержания, о которых говорится в статье Ивана Селиховкина Три фундаментальных принципа проектного управления.
Мы понимаем окончательную цель проекта - допустим, переход от зоопарка разных программ и приложений ("лоскутная автоматизация") на 1С: Комплексную автоматизацию. Но не знаем подробности: сроки, стоимость, и даже подробное содержание (бизнес-функциональные требования, а тем более технические задачи для выполнения этих требований).
Если и заказчик и исполнитель привыкли работать по водопаду, то на этой точке (неопределенность общих сроков, содержания и бюджета) дальнейшее сотрудничество может быть признано невозможным.

Но в Agile - все так и работают, и считают, что так и надо )))... Давайте попробуем разобраться, за счет чего это может получиться.

Водопад: его недостатки и ограничения

Водопад, несомненно, большой шаг вперед по сравнению с технологией “тяп-ляп” - здесь четко структурирован порядок деятельности.
Скажем, вот так выглядит технология корпоративного внедрения (ТКВ) от 1С, предполагающая последовательное внедрение по водопаду.

Весь проект разделен на четкие последовательные фазы, каждая из фаз регламентирована. 

 

В чем же основные недостатки водопадного подхода?

  • В начале проекта Заказчик не может написать хорошие требования 

Чем серьезнее и комплекснее проект внедрения, чем большие изменения бизнес-процессов компании предполагаются, тем сложнее Заказчику сформулировать, что именно ему требуется. Скажем, в ходе внедрения Документооборота в Почте России, эта проблема возникла в полный рост - будущие пользователи смутно понимали, что от них требуется.

  • Список требований пополняется до самого конца проекта

Очень часто, знакомясь с документами по тому или иному проекту, я встречаю упоминание пополнения списка требований в графе “Риски проекта”. Увы, по моему опыту, это скорее не риски, а ограничения проекта - я пока не видела ни одного проекта внедрения, где новые требования бы не появлялись в процессе. Может различаться только отношение к этим требованиям. Исполнитель может делать лицо кирпичом и отказываться их учитывать, ссылаясь на подписанный контракт. Но новые требования будут появляться обязательно (если заказчик хоть сколько-то вовлечен в процесс разработки и тестирования). 

  • Самые точные и полные требования Заказчик сформулирует  на стадии внедрения

Одна из типичных проблем при сборе требований, сформулированная Дмитрием Безуглым в его онлайн-курсе “Постановка задачи на разработку ПО” - “Заинтересованный стороны и пользователи думают, что знают, чего именно они хотят, до тех пор, пока им не дали именно то, что они попросили”. 
Опять же, можно обвинять в этой проблеме аналитиков и пользователей, но по мне, это примерно как обвинять небо, что идет дождь...

  • Аналитиков не волнуют трудности будущей разработки

В моей практике в больших командах внедрения часто возникают конфликты внутри команды между разными “лагерями”:
Аналитики обвиняют продажников, в том, что они обещали реализацию функционала, который с их точки зрения, мало возможен при помощи предложенного продукта.
Разработчики обвиняют архитекторов, что они призывают реализовать громоздкое и неработоспособное решение.
Тестировщики обвиняют разработчиков, что они пишут кривой код...
Ну, и так далее (кстати, как у вас? поделитесь в комментариях)... 

  • Заказчики не знают возможностей  и ограничений технологии

Любое внедрение, предполагающее смену инструментов с разной бизнес-логикой (переход с 7 на 8 бухгалтерию, переход с УПП на ERP и т. п.) обычно сопровождается довольно болезненными запросами “сделайте мне также как было” и объяснениями консультантов, почему именно это невозможно.  
С другой стороны, если заказчикам не приходит в голову, что приложение может решать какую-либо задачу, они и не включат запрос об этом в бизнес-функциональные требования.

  • Существуют проблемы (ошибки), о которых можно узнать только завершив работу в этой фазе и начав работу в следующей 

Кривые и непродуманные аспекты архитектуры очень часто становятся заметны только на этапе внедрения. Если в вашем проекте по занесению пианино на 17-ый этаж вы совершили ошибку на этапе планирования - неправильно выбрали подъезд - то вы ее заметите только перейдя к этапу внедрения в квартиру…

 

Agile: подход к сбору требований и написанию ТЗ


Итак, мы поговорили о проблемах и ограничениях водопадного подхода. Как же можно минимизировать эти проблемы? 
При помощи итеративности и инкрементальности. То есть выдавать конечный результат маленькими порциями (инкрементами), и осуществлять планирование на протяжении всего проекта (итеративно). Детализация требований при этом тоже осуществляется на каждом этапе отдельно. См, например, схему работы предлагаемую компанией 1С в технологии быстрого результата (ТБР), относящейся к гибким методологиям:

 

 

Детализация требований и планирование осуществляется на каждой фазе отдельно, то есть непонимание заказчиком своих запросов на старте уже не является проблемой. 


Работает ли Agile в ИТ-проектах и проектах внедрения 1С в частности?

В ходе вебинара для руководителей проектов мы провели опрос более чем 100 руководителей проектов внедрения 1С. И результаты опроса показали, что около 22% РП применяют гибкие методы в управлении проектами.

 

Используемые методологии

 

 

 

Мировой опыт тоже явно указывает на тенденцию перехода в Agile.
Скажем, очередной Chaos Report от Standish Group International показал, что шансы на успех ИТ проекта (то есть полное выполнение целей и удовлетворение заказчика) по Agile более чем в полтора раза выше, чем управляемого по водопаду. 

 

 


Итак. Мы выяснили, что Agile возможен, что уход от водопадной модели обладает некоторым количеством преимуществ. Теперь прикладной вопрос - как это может выглядеть на практике, при внедрении 1С-продукта?

Вариант первый.  Внедрение внутри предприятия своими специалистами.

Здесь, как мне кажется, Agile просто напрашивается. Большинство известных мне крупных успешных компаний, где ИТ-решения предлагают внутренние подразделения, постепенно уходят от крупных комплексных проектов, с тщательным продумыванием деталей на старте. Потому что к концу долгого водопадного проекта чаще всего выясняется, что проект успешно реализован согласно ТЗ, но… в таком виде уже давно никому не нужен. 
Как выглядит управление проектом по Agile в этом случае?
На старте четко понимается целевой результат. На старте максимально четко понимается архитектура решения в целом. На старте формулируются наиболее важные бизнес-функциональные требования. На старте определяется функционал первого релиза. На старте мы не пытаемся понимать весь бюджет, сроки внедрения в целом, полный объем содержания. Дальше проект запускается, и обеспечивается взаимодействие между ключевыми заинтересованными сторонами.

Вариант второй. Внедрение во внешней организации. Серия небольших договоров. 

Как уже описывалось выше, в начале проекта заказчик и исполнитель не пытаются понять общую стоимость, продолжительность и содержание проекта. В начале - оформляется рамочное соглашение, договор о намерениях, включающий общую цель. Дальше заключается серия небольших контрактов, каждый из которых предполагает законченный результат, подлежащий использованию. Неоднократно наблюдала компании франчайзи, которые успешно выполняли многомиллионные контракты на крупные компании/холдинги “по кусочкам” - каждый конкретный контракт заключался на небольшую сумму. 

Вариант третий. Внедрение во внешней организации. Один большой контракт. 

Вариант, описанный выше, хорош, но не всегда возможен. Скажем, когда у вас идет речь о госконтракте, объявляется тендер, подписывается договор на старте - и в нем должны быть жестко зафиксированы сроки, бюджет и содержание ТЗ. Как можно действовать в такой ситуации? Мы же помним все те недостатки водопадного метода, про которые мы говорили в начале статьи - заказчик физически не способен на старте четко сформулировать исчерпывающие требования, появление новых требований и уточнение старых в ходе проекта неизбежно. 
Чтобы иметь возможность применять гибкие подходы Agile, вам нужно суметь реализовать две лазейки.
Во-первых, не пытаться четко прописывать подробные требования на старте. На старте в ТЗ указываются высокоуровневые требования, а дальше они, по методу набегающей волны, детализируются уже в ходе проекта. 
Во-вторых, заложить в контракт опцию замены требований на аналогичные по трудоемкости. Знакомая, думаю, всем ситуация - в ходе проекта заказчику становится понятно, что ему крайне необходим дополнительный функционал. При этом контракт подписан и утвержден на старте, и исполнитель не жаждет делать дополнительные работы за бесплатно. В такой ситуации можно предложить заменить часть функционала из контракта, которую заказчик на настоящий момент оценивает как менее ценную, на новые функции. Причем приоритетность функций (что важнее всего) оценивает заказчик, а трудоемкость работ (что значит “заменяем работу на аналогичную”) - исполнитель. 
Важно, чтобы договор предполагал выполнение работ по этапам, и была возможность при помощи дополнительных соглашений менять состав работ на каждом этапе. 
Скажем честно, на практике так очень часто в водопадных проектах и делают “мимо договора”, просто “договариваясь по понятиям”... Но в этой ситуации мы имеем расхождение между документом и действительностью, что осложняет дальнейшее сопровождение и вообще усложняет коммуникацию. Оптимальное решение, повторюсь, указано выше - заложить в условия договора возможность замены одного функционала на другой.


Ограничения Agile 

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


Что мешает внедрять Agile?

  • Как я писала в предыдущей статье - гибкие методы подходят для проектов с высокой степенью неопределенности требований, высокой степенью технической неопределенности и возможностями частых поставок. 
  • Agile ограниченно подходит для решений со сложной архитектурой. Компания 1С, разработавшая Технологию быстрого результата (ТБР), по сути, являющуюся фреймворком в рамках гибких методологий, не рекомендует применять ее для сложных архитектурных решений. Потому что частыми маленькими релизами как раз легко сломать типовую архитектуру и нагородить решений, которые сложно будет использовать для других задач.
  • Гибкие методы подразумевают очень сильное вовлечение специалистов заказчика (вплоть до участия в определении фич в начале каждой итерации) - а это время заказчика и немалое. Не все заказчики к этому готовы.
  • Неопределенность бюджета и сроков проекта усложняет коммуникацию с руководством заказчика
  • При работе по небольшим кусочкам заказчик всегда может разорвать контракт с исполнителем посередине, или отложить реализацию следующего фрагмента. Это удобно заказчику, но уменьшает уверенность исполнителя в завтрашнем дне. Разрывы между итерациями увеличивают себестоимость проекта.


Что помогает внедрять Agile на практике?

  • Отношения, основанные на доверии, и готовность обеих сторон к сотрудничеству.
  • Приемка каждую итерацию. Или хотя бы демонстрация заказчику.
  • Документальная фиксация согласия заказчика с промежуточным результатом - актировать этапы.
  • Вовлечение в тестирование на промежуточных стадиях широкого круга пользователей от заказчика (зачастую против воли основного представителя заказчика)
  • Практически любой заказчик хочет быстрый результат. Поэтому обещанием работающего инкремента с урезанным функционалом по итогам первой итерации - позволяет уговорить заказчика на применение гибких методологий.
  • Обжегшись на молоке заказчики начинают дуть на воду. Если у заказчика был опыт неудачных ИТ-проектов по водопаду - уговорить его на Agile будет несколько проще ))).

Резюме данной статьи хорошо сформулировал мой коллега, Дмитрий Кузнецов: 

Использование гибких методов не гарантирует успех проекта. Но в некоторых ситуациях (например, высокой неопределенности требований) не применение Agile предопределяет его провал...

В следующей статье я расскажу про то, какие техники и инструменты по сбору и приоритизации требований предлагают гибкие методологии. Следите за обновлениями.

 

Подробнее об управлении ИТ-проектами вы можете узнать на моих онлайн-курсах 

См. также

Работа с требованиями Проектирование Удобство использования (UX) Программист Бесплатно (free)

Расскажем о том, как снизить риски при разработке мобильных приложений, новых конфигураций или целых подсистем «с нуля». Материал будет актуальным и для компаний-интеграторов, и для сотрудников внутренних ИТ-отделов в производственных или торговых компаниях.

17.04.2024    1444    16    Vladimir_Konyrev    1    

6

Компетенции и навыки РП Работа с требованиями Бесплатно (free)

Аналитики 1С не всегда хорошо представляют себе, в каких таблицах системы хранятся данные, и из каких объектов состоит конфигурация. Как следствие – технические задания часто получаются непонятными для разработчиков. Расскажем о том, зачем аналитику разбираться в таких темах, как конфигуратор и структура метаданных, регистры, запросы, СКД, интеграция и обмен данными.

02.02.2024    2099    0    otkalo    1    

12

Работа с требованиями Бесплатно (free)

С выходом ChatGPT стала общедоступна генерация текстов, очень похожих на творчество человека. Использование этой технологии может здорово облегчить вам жизнь и избавить от рутины, но только если вы сами хорошо понимаете – чего вы от него хотите, в каком виде и в какой последовательности. О том, как применить генеративные модели в работе аналитика, пойдет речь в статье.

22.12.2023    2730    0    Ykkks    4    

16

Работа с требованиями Бесплатно (free)

Проработка нефункциональных требований (НФТ) часто вызывает трудности у аналитика, но если этими требованиями пренебречь, вероятность проблем в проекте увеличивается. Расскажем о том, что такое нефункциональные требования, почему они важны, как их классифицировать и как выстроить процесс работы с ними так, чтобы они помогли улучшить конечный продукт.

21.12.2023    2061    0    user1909204    0    

5

Работа с требованиями Бизнес-аналитик Руководитель проекта Бесплатно (free)

На комплексных проектах внедрения часто приходится уточнять, что входит в контур автоматизации, и гармонизировать встречные требования заинтересованных сторон. Особенно это актуально для таких процессов, как Планирование (продаж, производства, закупок и т.д.). Расскажем об инструментах, которые позволят состыковать требования к системе так, чтобы они были полными, не противоречили друг другу, и обеспечивали качественную автоматизацию процессов.

08.12.2023    851    0    e_ivanova    1    

7

Кейсы автоматизации Работа с требованиями Анализ бизнес-процессов Бесплатно (free)

Автоматизировать производственные процессы в 1С:ERP без доработки типовых механизмов очень сложно. А дорабатывать типовые механизмы 1С:ERP не всегда оправданно. Решением может стать технология разработки Рабочих мест, которая позволяет автоматизировать самые сложные участки последовательно – шаг за шагом, процесс за процессом. Расскажем о том, как помочь пользователям вводить большое количество данных, не нарушая порядок ввода и полноту заполнения всех необходимых реквизитов, и как вовлечь сотрудников Заказчика в разработку и тестирование функционала Рабочих мест.

26.10.2023    2375    0    user1754524    15    

17

Работа с требованиями Программист Бизнес-аналитик Руководитель проекта Бесплатно (free)

Всем известны истории про то, как заказывали велосипед, а получили мотоцикл по цене автомобиля. Чтобы оправдать ожидания заказчика и удовлетворить потребности пользователей, при сборе требований нужен комплексный подход. 

22.09.2023    1897    0    user1615644    0    

3

Работа с требованиями Бесплатно (free)

Внедрение крупной системы – это большой и сложный процесс, в котором принимают участие десятки сотрудников. В этих условиях актуально формализовать подходы к выполнению этапов проекта, чтобы сократить время на написание и обновление документации, получить документацию в едином стиле, а также накапливать опыт по проектным решениям в одном месте. Статья о том, как адаптировать методологию AIM под специфику проектов 1С и организовать моделирование и проектирование систем класса ERP в едином контексте, используя СППР.

16.08.2023    3396    0    Libelle    0    

19
Комментарии
Подписаться на ответы Инфостарт бот Сортировка: Древо развёрнутое
Свернуть все
1. Крококот 30.08.18 06:50 Сейчас в теме
•Отношения, основанные на доверии, и готовность обеих сторон к сотрудничеству.

Вы часто встречаете подобные отношения в проектах по внедрению? Да вообще в бизнесе.
Многих проблем можно было бы избежать, много подходов поменять, много работы не делать, если бы отношения, основанные на доверии встречались бы чаще.

•Неопределенность бюджета и сроков проекта усложняет коммуникацию с руководством заказчика

Я бы сказал "нередко делает невозможной."
Тот же дефицит доверия.

Agile неплох для внедрения силами "внутренних" программистов, хотя и там водопад применяют просто потому что не доверяют своим сотрудникам. Для более или менее крупного внедрения сторонней организацией... очень хотелось бы узнать как РП сумел договориться с руководством организации на внедрение "с неопределенным сроками и бюджетом".
Fejerverk; maxx; +2 Ответить
4. MariaTemchina 1620 30.08.18 10:36 Сейчас в теме
(1)
очень хотелось бы узнать как РП сумел договориться с руководством организации на внедрение "с неопределенным сроками и бюджетом".

Подстава заключается в том, что Водопад дает скорее иллюзию внедрения с определенным сроком и бюджетом... Потому что на практике результат очень часто оказывается неработоспособным. И организации (в том числе крупные) скрепя сердце соглашаются на Agile.
(Ну, или не соглашаются. Но статья про тех, кто соглашается - и их с каждым годом все больше).
5. Крококот 30.08.18 11:26 Сейчас в теме
(4)
Во-первых, вы явно недооцениваете иллюзии... на них в нашем мире делают огромные деньги. Более того, они очень нужны многим людям.
Во-вторых, суть в том, что водопад вместе с иллюзией даёт хоть какую-то определенность. Четкие сроки и сумму. Да, потом это поменяется десять раз, но все же есть хоть какая-то база. А что пишут в договоре на внедрение по agile? Клиент обязуется исправно платить за некие работы не имея реальной возможности потребовать результата, т.к. появление этого результата не обусловлено ни наступлением какой-либо даты, ни выплатой определенной суммы?
makushka; +1 Ответить
10. MariaTemchina 1620 30.08.18 13:50 Сейчас в теме
(5)
Во-первых, вы явно недооцениваете иллюзии... на них в нашем мире делают огромные деньги. Более того, они очень нужны многим людям.
- несомненно. Иллюзии вообще очень ценная вещь, факт!.. Мы говорим про ту ситуацию, когда участники хотят результат, имеющий бизнес-ценность, и дозрели ради этого до отказа от иллюзий.

Клиент обязуется исправно платить за некие работы не имея реальной возможности потребовать результата, т.к. появление этого результата не обусловлено ни наступлением какой-либо даты, ни выплатой определенной суммы?

Вот здесь-то собака и порылась! Что у них должен быть промежуточный результат, пригодный или потенциально пригодный к внедрению. И на промежуточном этапе в принципе можно заплатить деньги за то, что уже готово, и отправить Agile-исполнителя гулять восвояси...
13. Крококот 31.08.18 05:39 Сейчас в теме
(10)
у них должен быть промежуточный результат, пригодный или потенциально пригодный к внедрению

А у кого "у них"? У клиента? У внедренца?
Этот промежуточный результат и сроки его наступления закрепляются в договоре или нет? Он имеет предварительно установленную стоимость? Что помешает внедренцу кормить клиента завтраками и получать деньги за этот будущий промежуточный результат, если всего этого нет?
Кто определяет потенциальную пригодность результата к внедрению другим внедренцем? Кто оценивает шансы на то, что другой внедренец не скажет "да тут всю систему менять надо, нагородили тут ерунды всякой, архитектура ни к черту"?
makushka; LordKim; acanta; +3 Ответить
2. Steelvan 305 30.08.18 08:17 Сейчас в теме
Дочитал до англицизма "Дисклеймер", про себя ругнулся и закрыл статью.
На русском писать можно ?
Все меньше и меньше хочется заходить на этот сайт.
makushka; Yakud3a; papche; +3 2 Ответить
3. MariaTemchina 1620 30.08.18 10:20 Сейчас в теме
(2) Steelvan - радует, что название книжки, упомянутое в начале статьи, выше слова "Дисклеймер", не затруднило чтения.
andrvyst; genayo; +2 Ответить
6. beefit 30.08.18 11:51 Сейчас в теме
Прочитав заголовок, хотел зайти и написать: "Никак".
А у вас это в начале написано)
MariaTemchina; +1 Ответить
8. MariaTemchina 1620 30.08.18 13:43 Сейчас в теме
7. d.zhukov 1427 30.08.18 11:53 Сейчас в теме
Информация, основанная на полученном опыте: на начальном этапе всего 20-30% процентов могут сформулировать требования, остальные выражают абстрактные мысли. И даже та часть клиентов с вероятностью в 50 процентов все переиначивают на этапе разработки, внедрения и знакомства с продуктом. Назвать первоначальные общения с клиентом "постановкой задач" не поворачивается язык. Я называю этот этап "Предварительная ласка"))
itriot11; Yakud3a; Fejerverk; CSiER; MariaTemchina; +5 Ответить
9. MariaTemchina 1620 30.08.18 13:44 Сейчас в теме
(7) d.zhukov - точная характеристика процесса, что-то есть )))
11. Steelvan 305 30.08.18 21:06 Сейчас в теме
Если нормальный человек, который пишет для взрослых людей, напишет "Отступление" или "Отказ от ответственности", то
автор, который держит читателей за толпу уровня школоты, пишет "Дисклеймер".
Сугубо мое персональное мнение.
user1731057; +1 Ответить
12. acanta 31.08.18 00:08 Сейчас в теме
На начальном этапе 5% специалистов обладают достаточной квалификацией для того чтобы выполнить даже достаточно четкие и адекватно сформулированные требования 20-30% заказчиков.
makushka; +1 Ответить
14. acanta 31.08.18 11:58 Сейчас в теме
1.Пришел новый дворник. Получил старую метлу в целости и сохранности. Новый дворник "даже крыльцо нормально подмести не может".
Старый дворник не может получить денег на новую метлу потому что старую метлу еще можно подремонтировать, можно собрать хворост на улице и перетянуть шнурками от ботинок или леской от удочки (ну, ты же рыбак..).
2. За что Герасим утопил свое Му-му..
Ситуация такова, что заказчики сейчас требуют аванс/залог от исполнителей. Но поскольку у исполнителей единственный источник дохода - разработка конфигураций, денег нет, то аванс называется функциональная модель или рабочий прототип (опытный образец). Как можно оформить что такая работа это именно аванс разработчика заказчику? Каковы методы оценки ее стоимости в случае передачи функциональной модели третьим лицам? По себестоимости / по стоимости повторной разработки функциональной модели?
15. MariaTemchina 1620 31.08.18 12:09 Сейчас в теме
(14) Образы красивые, но, если совсем честно, я не совсем поняла, какие именно тезисы статьи они призваны проиллюстрировать..
16. acanta 31.08.18 12:48 Сейчас в теме
Например точки зрения "абстрактной бухгалтерии" клиента разработку конфигурации можно определить как нематериальный актив, с достаточно частой модернизацией в момент получения результатов очередного спринта и установленным сроком амортизации.
Амортизация такого актива начинается в момент его промышленной эксплуатации и можно дальше развивать тему различного определения остаточной стоимости разработки на стороне разработчика и заказчика, на случай передачи/продажи разработки третьим лицам и получением дохода третьими лицами от четвертых, пятых, шестых..
Функциональная модель же предполагает что она "как есть" никогда не будет передана в промышленную эксплуатацию. Ее незавершенность есть неотъемлемое и обязательное качество. Так же как и эксклюзивный продуктив в промышленной эксплуатации не может быть "как есть" передан/установлен третьим лицам физически. Если таковое возможно - это не эксклюзивный продуктив, а коммерческая разработка.
Таким образом коммерческую ценность разработки имеют только тогда, когда за них можно и не платить, как это ни парадоксально.
17. acanta 31.08.18 15:03 Сейчас в теме
Для меня agile это покупка джинсов на вырост, которые сначала подрезали и подшили, а затем надставляем/расшиваем/ушиваем по мере необходимости. Результат маловероятно будет удовлетворять понятию "бесшовная интеграция". Agile предполагает кроме неопределенности требований еще и экономию на квалификации внедренцев за счет полной смены команды внедренцев на каждом спринте/блоке спринтов и постоянный поиск лучших участников проекта по соотношению цена/качество. Любые технологии к сожалению описывают поведение одной проектной команды. Проблема в том, что количество команд, которые можно привлечь к проекту на каждом конкретном этапе к спринту не бесконечно.
И отношение при каждом обращении клиента к команде разработчиков будет менятся с учетом опыта, полученного в других проектах.
Следует учитывать тот нюанс, что клиент, обратившийся к разработчику в третий раз дважды отказался от его услуг.
user1731057; +1 Ответить
18. RustIG 1720 04.09.18 12:14 Сейчас в теме
(0) сажаете разработчика в отдел - пусть работает на ряду с пользователями - оформляет заявки, отгружает товары, обслуживает клиента, формирует отчетность и т.д. Я только так понимал, что нужно заказчику от системы. При этом большая часть айсберга дорабатывалась уже чисто для удобства работы (в том числе проверки, подсказки, раскраски).
19. teller 05.09.18 14:57 Сейчас в теме
(18)
сажаете разработчика в отдел - пусть работает на ряду с пользователями - оформляет заявки, отгружает товары, обслуживает клиента, формирует отчетность и т.д. Я только так понимал, что нужно заказчику от системы. При этом большая часть айсберга дорабатывалась уже чисто для удобства работы (в том числе проверки, подсказки, раскраски

как жеж так , это ведь подход тупого кодера. А где собственные компетенции в предметной области? Где передовой опыт отрасли? С таким взглядом клиент получить только три мешка говнокода и автоматизацию собственного кондового уклада жизни.
20. RustIG 1720 05.09.18 17:53 Сейчас в теме
(19) 99% работ делаются без выезда по удаленке - тут и компетенция, и передовой опыт отрасли. про остальное - не могу судить.
21. teller 06.09.18 05:02 Сейчас в теме
(20)
сажаете разработчика в отдел - пусть работает на ряду с пользователями

-как Карл ! если
99% работ делаются без выезда по удаленке
29. RustIG 1720 23.08.20 23:17 Сейчас в теме
(21)
сажаете разработчика в отдел - пусть работает на ряду с пользователями - оформляет заявки, отгружает товары, обслуживает клиента, формирует отчетность и т.д

Разработчик садится рядом с пользователями, но не для того, чтобы программировать, а чтобы делать пользовательскую работу. Три раз нажмет на кнопку - задумается, что надо автоматизировать - сформулирует для себя ТЗ.

Сама разработка происходит уже в своем офисе на удаленке.

Сдача работ происходит снова на объекте у клиента. При сдаче работ происходит не просто обучение, а наблюдение за действиями пользователя: куда нажал, почему нажал, зачем нажал. Собирается портрет доработок.

Дорабатываете уже на удаленке, используя передовой опыт отрасли.
30. teller 28.08.20 08:02 Сейчас в теме
31. RustIG 1720 28.08.20 09:11 Сейчас в теме
(30) если есть вопрос, значит было недопонимание. было у вас - значит будет у других.
вопрос увидел спустя два года - принципы сопровождения программ 1с и клиентов не изменились...
ответ не только вам адресован - он в принципе дан в связи с тем, что я может не полностью выразил мысль...
22. Valerych 11.09.18 17:37 Сейчас в теме
Возьмем пример сложного внедрения.

Организация планирует переход на 1С ERP (можно подставить 1С УПП, Аксапту или продукт подобного класса). Старая система решала задачи автоматизации не похожим на новую систему путем, т.е решала, но как-то своим путем, но и не все решала, потому отчасти и меняют.
Подсистемы логистики закупок, логистики отгрузок, казначейство, модули оперативного производства требуют серьезных доработок типовой под специфику предприятия.
Переход на новую систему планируется с единовременным отключением старой системы.
Как допустимое отклонение для страховки возможно 3 месяца параллельной работы в 2-х системах при готовности системы для полного отражения первички и оперативного учета, при неготовности условного зарплатного модуль или к примеру модуля казначейства.

При таких условиях подходу инкремент+итерация приказали долго жить.
Ну представим себе много мелких поставок - вот запустили логистику закупок, через 2 недели подключили запасы на складе, еще через 2 недели спринт принес логистику продаж, еще через несколько спринтов нет вопросов к первичным документам, а после еще десятка спринтов ... мы проснемся и идея инкремент+итерация так и останется сном.

Частая головная боль внедрений по методу водопада идет от того простого факта, что Заказчик может вменяемо и детально рассказать, что он хочет от системы только поработав с ней.
Работали ли с 1С 7.7 и переходят на Аксапту или работали с 1С УПП и переходят на 1С ERP 2.4, если не знакомы ответственные за требования с новой системой, возникает тот самый риск недостаточной определенности требований.

Не зря имеет место быть формула "лучшее внедрение делает вторая команда", когда Заказчик уже менее капризен в плане требований и хотелок, знаком с системой.
Рецепт очевиден, хочешь улучшить практику сбора требований и успешность внедрений, становись "второй командой" ... или ...

PMI хоть и консервативны, но они развиваются, умеют учитывать окружающие реалии.
И кроме agile они не упустили из виду такой инструмент сбора требований как использование прототипов.

При внедрении 1С 8.х прототип просто просится в ситуациях, когда типовой функционал не справляется с требованиями, а доработка требований это нечто глобальное, собственно и есть сам проект (или его часть), но(!) решение похожее на изложенное в требовании, пусть и очень черновое, можно сваять с минимальными трудозатратами.

В этом месте метод прототипов перекликается с манифестом agile в части сотрудничества и вовлеченности, без которых никак.
И вот при этой самой вовлеченности можно получить достаточно приближенный к реальности набор требований к системе, основанный на:

1. Типовом функционале.
Внедряем все же не с нуля и многое из требований уже готово, типовая частично и сама есть прототип, помогающий детализировать требования.

2. Прототипах того функционала, которого нет, но который можно показать "как могло бы быть" на примерах.

3. Более сложный вариант прототипа, который в методе водопада находится на этапе разработки или иногда на этапе обучения. Но точно до старта промышленной эксплуатации.
Если инициировать "1 день работы подразделения" с сырым, но рабочим функционалом для получения обратной связи, можно одолеть целый список рисков, понизив неопределенность требований, и даже среагировав на нечто вновь появившееся.

В качестве итога.
Метод водопад + прототипы на разных стадиях проекта совершенно не панацея и не самое лучшее решение.
Но это инструмент для управления проектом, способный минимизировать риски, а при вовлеченности заказчика еще и позволяющий вернее оценить затраты проекта.
Даже при использовании прототипов нет 100% уверенности в точности всех требований. Ибо только поработав в системе Заказчик полнее знает, что хочет. В этом месте (при планировании проекта) нужно закладывать в бюджет как часть проекта несколько человеко-месяцев разработки/доработки ... после старта промышленной эксплуатации.
Мы практически открыто говорим, как бы ни старались, мы промахнемся с реализацией требований, все равно после старта промышленной эксплуатации будут доработки, объективно будут.
И закладываем еще один этап разработки+имплементации, но уже как развитие новой системы, а не как переход на нее (хотя при классическом водопаде это "исправление ошибок" на этапе промышленной эксплуатации).
И да, для этих самых месяцев с момента старта промышленной эксплуатации почти идеально подходит концепция agile.
MariaTemchina; +1 Ответить
25. MariaTemchina 1620 12.09.18 15:54 Сейчас в теме
(22) Спасибо за столь развернутый и конструктивный комментарий!

Я генерально согласна с вами по существу, только немножко предлагаю уточнить терминологию

Переход на новую систему планируется с единовременным отключением старой системы... При таких условиях подходу инкремент+итерация приказали долго жить.

Совсем нет! Почитайте идеологов. Скажем, того же Джеффа Сазерленда, автора Скрама. Он вполне себе описывал проект, управляемый по Скрам с единой поставкой в конце. А в конце каждой итерации - те же самые прототипы, про которые вы рассказываете. Это, конечно, хуже, чем много маленьких поставок. Но лучше, чем обсуждение на словах.



Метод водопад + прототипы на разных стадиях проекта совершенно не панацея и не самое лучшее решение.


Мне кажется, что то, что вы описываете как "водопад + прототипы" - это как раз и есть то, что называется итеративный метод - когда мы не пытаемся планировать всю систему на старте целиком, а по итогам изучения прототипов изучаем требования.
См. мою статью Можно ли объять необъятное или чем Agile отличается от водопада
27. Valerych 13.09.18 17:33 Сейчас в теме
(23)

Если Заказчик поработал несколько лет и не знает, что хочет от системы, любая методика бессильна.
Разве что концепция "второго" внедрения ...
28. Valerych 13.09.18 17:41 Сейчас в теме
(25)

Марина, то что я называю прототипами как-то многократно пересекается с тем, что Вы описываете, представляя agile.
И хотя все-таки это разные термины, да и инструменты, тем не менее, или при их использовании много общего, или я слишком обширно и нечетко использую понятие прототип.

Наверно возможно прописать некую модель интеграции водопад + прототипы в понимании PMBOK + agile, в ней описать роль и место прототипов, роль и место agile, сделать это отдельно для на стадии сбор требований, затем для стадии разработка.
И вряд ли понятия прототип и agile окажутся смешанными или одной и той же сущностью, например как бэклог окажется сущностью, которой прототип не является.

Может быть agile на этапе сбора требований окажется применимым в качестве инструментария менеджмента, организации групп, а областью бэклог окажется список требований с высокой степенью неопределенности.
А прототип это в данном контексте это некая форсированная разработка (в классическом водопаде преждевременная), но тем не менее уместная в силу низких затрат на голый и полусырой функционал прототипа. И с помощью прототипов будет таять список бэклогов.
Опять же манифесты agile в том месте, где речь о взаимодействии, жизненно необходимы для успешности прототипов в снятии неопределенности требований.

На стадии разработки прототипы и agile могут взаимодействовать уже как-то иначе.
Например все требования могли оказаться собранными очень четко и тогда почти вуаля (для несложных доработок).
С другой стороны, для сложных доработок, а может даже для типового функционала может оказаться важной "преждевременная" (до наступления сроков опытной или промышленной эксплуатации всей системы) "боевая" эксплуатация на примере реального периода работы с реальными данными (1 или несколько дней работы в 2-х системах).
Это важно для фиксации успешности реализации требованиях путем получения достоверной обратной связи от ключевых пользователей поработавших не на бумаге в новой системе.

И для этой стадии вероятно можно расписать менеджмент в духе agile и порядок и процедуры работы с прототипами.

А может быть все проще и в силу того, что среда обитания прототипов и agile оказалась близкой (пи сборе требований), когда Вы Марина описываете agile, я заблуждаюсь, читая слово "прототип" вместо "agile".
26. MariaTemchina 1620 12.09.18 15:57 Сейчас в теме
(22)
Даже при использовании прототипов нет 100% уверенности в точности всех требований. Ибо только поработав в системе Заказчик полнее знает, что хочет. В этом месте (при планировании проекта) нужно закладывать в бюджет как часть проекта несколько человеко-месяцев разработки/доработки ... после старта промышленной эксплуатации.
Мы практически открыто говорим, как бы ни старались, мы промахнемся с реализацией требований, все равно после старта промышленной эксплуатации будут доработки, объективно будут.


Да, и эта схема тоже вполне укладывается в подход Agile. Когда мы на первом этапе выделяем тот функционал, без которого система работать не будет. Налепляем на него минимально осмысленный функционал ("walking skeleton") - и это и входит в первую поставку. А дальше у нас много итераций (например, как вы и описываете, в ходе промышленной эксплуатации), когда мы допиливаем уже не критичный функционал.
23. acanta 11.09.18 18:44 Сейчас в теме
Даже поработав в системе несколько лет Заказчик может не знать чего хочет от системы. Но после запуска нескольких оперативных контуров он может это и узнать.
Опасность в том, что вместо запуска всей новой системы эти части могут быть перенесены в старую и заказчик будет удовлетворен, а проект в целом вернется от внедренцев к поддержке. На agile эта вероятность еще выше.
В качестве страховки можно предложить единовременный запуск оперативных контуров на новой системе и обратную синхронизацию данных с существующей, а для этого потребуется знать существующую систему достаточно хорошо и их поддержка должна будет обеспечить эту синхронизацию со своей стороны.
Кроме того, что список первоочередных задач/багтрек и требования к новой системе опять таки будет составлять и предоставлять поддержка существующей системы. Готовы ли 1с ники взять на себя поддержку например Аксапты полностью на время предпроектного обследования? И если да, то готовы ли они при этом внедрять 1с какую нибудь?
24. MariaTemchina 1620 12.09.18 11:56 Сейчас в теме
(23)
Опасность в том, что вместо запуска всей новой системы эти части могут быть перенесены в старую и заказчик будет удовлетворен, а проект в целом вернется от внедренцев к поддержке. На agile эта вероятность еще выше.

В Agile вообще по определению выше вероятность того, что проект пойдет не так, как планировалось изначально. Если у нас есть высокая уверенность в том, как делать проект, нам Agile в принципе обычно не нужен, достаточно водопада (ну, или итеративной модели).
Оставьте свое сообщение