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

Публикация № 894886

Методология - Управление проектом

57
В этой статье я расскажу, как гибкие и классические подходы к управлению проектами предлагают обходиться с требованиями заказчика. А заодно поделюсь опытом руководителей проектов, за счет чего можно убедить заказчиков работать по методологии 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 предопределяет его провал...

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

57

Специальные предложения

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

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

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

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

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

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

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

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

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

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

-как Карл ! если
99% работ делаются без выезда по удаленке
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 844 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 844 12.09.18 15:57 Сейчас в теме
(22)
Даже при использовании прототипов нет 100% уверенности в точности всех требований. Ибо только поработав в системе Заказчик полнее знает, что хочет. В этом месте (при планировании проекта) нужно закладывать в бюджет как часть проекта несколько человеко-месяцев разработки/доработки ... после старта промышленной эксплуатации.
Мы практически открыто говорим, как бы ни старались, мы промахнемся с реализацией требований, все равно после старта промышленной эксплуатации будут доработки, объективно будут.


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

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

См. также

20 мыслей об ИТ-проектах. Мысль №3. "О правильных требованиях к системе" 24

Статья no Нет файла Бесплатно (free) Управление проектом

Очередной темой серии статей “20 мыслей об ИТ-проектах” будут требования к системе. По результатам голосования был вариант про карьеру проектных ИТ-специалистов, но ее я коснулся в докладе на Воронежском митапе, немного изменив и сделав акцент в сторону аналитиков. В ближайшем выпуске сделаю небольшую выдержку по теме.

14.10.2019    2894    chavalah    16       

Онлайн-курс "Технология выполнения проектов ERP-класса – процессный подход". Третий поток. Курс проходит с 21 января по 18 марта 2020 года. Промо

Курс разработан Внедренческим центром «Раздолье». Курс предназначен для подготовки аналитиков, архитекторов и руководителей проектов автоматизации процессов управления с использованием комплексных ИТ-систем (1С:ERP, 1С:УХ, 1С:КА, 1С:УТ). В основе курса лежит методика применения процессного подхода.

9000 рублей

Незакрытый проект на 1000 часов 65

Статья no Нет файла Россия Бесплатно (free) Управление проектом

История о незакрытом проекте, о бессонных ночах, о попытках его выгрести, о бесплатной работе, о вселенской боли.

19.09.2019    7937    ogroup    156       

Стратегия выживания в корпоративных войнах 47

Статья no Нет файла Бесплатно (free) Управление проектом

Айтишникам сложно строить карьеру управленца. И все потому, что в их «техническое ДНК» не заложено умение справляться с окружающими их интригами. Однако, поскольку это навык, это можно исправить, считает ИТ-директор в ПАО «Светлана». На конференции Infostart Event 2018 он поделился с коллегами, что и как надо делать, чтобы не погрязнуть в корпоративных интригах и сделать так, чтобы они не мешали выполнению основной работы.

16.09.2019    5341    GSoft    14       

С 2020 года сервис «Продление поддержки конфигурации 1С:УПП» подорожает вдвое Промо

Успейте продлить поддержку УПП до повышения цен! Фирма «1С» предупредила об изменении цен на сервис «Продление поддержки конфигурации "1С:Управление производственным предприятием"». С 1 января 2020 года сервис подорожает в два раза.

Мастер-класс СППР 44

Статья Программист Руководитель проекта Нет файла Бесплатно (free) Управление проектом СППР

Сергей Наумов, в прошлом разработчик подсистемы бюджетирования в конфигурации «1С:ERP», на мастер-классе конференции INFOSTART EVENT 2018 EDUCATION поделился опытом управления проектами с помощью «1С:Системы проектирования прикладных решений» и показал, как использовать эту программу в работе над разными задачами: для сбора, классификации и хранения требований; для управления разработчиками и консультантами; в качестве системы документирования; в качестве баг-трекера на этапе опытно-промышленной эксплуатации.

30.08.2019    5234    SergeyN    4       

Новый раздел на Инфостарте - Electronic Software Distribution Промо

Инфостарт напоминает: на нашем сайте можно купить не только ПО, связанное с 1С. В нашем арсенале – ESD-лицензии на ПО от ведущих вендоров: Microsoft, Kaspersky, ESET, Dr.Web, Аскон и другие.

  • Низкие цены, без скрытых платежей и наценок
  • Оперативная отгрузка
  • Возможность оплаты с личного счета (кешбек, обмен стартмани на рубли и т.п.)
  • Покупки идут в накопления для получения скидочных карт лояльности Silver (5%) и Gold (10%)

Как заработать миллион или История успешного сотрудничества 46

Статья Программист Нет файла Бесплатно (free) Управление проектом

Многие мечтают один раз что-то создать, а потом жить на заработанные деньги до конца своих дней. Но миллионерами становятся не все, их единицы. Среди них – разработчик Андрей Карпов. Человек, который сумел за полтора года заработать 2 миллиона рублей чистой прибыли, поделился с гостями конференции Infostart своими секретами.

05.08.2019    4900    karpik666    77       

Бизнес-аналитика с помощью Power BI 68

Статья Руководитель проекта Нет файла Бесплатно (free) Управление проектом

Тема статьи – это бизнес-аналитика. Возможно, кто-то этого не знает, но внедрение бизнес-аналитики – это очень больно. Когда внедряются не просто какие-то дашборды, а действительно бизнес-аналитика, происходит увольнение большого количества сотрудников, потому что выясняется, что они не выполняют те функции, которые на них возложены.

11.07.2019    7688    pbazeliuk    18       

Программы для исполнения 54-ФЗ Промо

С 01.02.2017 контрольно-кассовая техника должна отправлять электронные версии чеков оператору фискальных данных - правила установлены в 54-ФЗ ст.2 п.2. Инфостарт предлагает подборку программ, связанных с применением 54-ФЗ, ККТ и электронных чеков.

Управление проектами по автоматизации бюджетирования 37

Статья Бизнес-аналитик Руководитель проекта Нет файла УУ Финансовый учет и бюджетирование (FRP) Бесплатно (free) Управление проектом

Автоматизация бюджетирования позволяет максимально эффективно планировать ресурсы предприятия и управлять масштабированием компании. Как учесть особенности бюджетирования, встроить его в процессы стратегического планирования, чтобы получить гибкий инструмент управления и аналитики, рассказал Сергей Наумов на конференции INFOSTART EVENT 2018 EDUCATION.

28.06.2019    3998    SergeyN    1       

Внедрение решений: как выполнять все обязательства в срок в условиях ограниченных ресурсов 23

Статья Руководитель проекта Нет файла Бесплатно (free) Управление проектом

Многие менеджеры вынуждены работать в условиях многоклиентской среды с ограниченными ресурсами. И вовремя сдавать проекты в таких условиях сложно. Как добиться того, чтобы поставки делались без нарушений сроков, рассказал гостям и участникам конференции Infostart Event 2018 управляющий партнер BIPULSE.RU Алексей Васильев.

24.06.2019    3306    sbase    9       

Перенос данных БП 3.0 => УТ 11 / КА 2 / ERP 2 (ЕРП) (перенос остатков, документов и справочной информации из "1С:Бухгалтерия предприятия 8", ред.3.0). Обновлено до БП 3.0.73.х, УТ 11.4.10.х, КА 2.4.10.х., ERP 2.4.10.х! Промо

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

29700 руб.

Риск - благородное дело!.. Часть первая 31

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

Несколько рекомендаций по управлению рисками в ИТ-проектах.

18.06.2019    4454    MariaTemchina    8       

Мы в ответе за то, чего вовремя не послали. Матрица ответственности в проектах внедрения 33

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

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

31.05.2019    4793    MariaTemchina    23       

Перенос данных УТ 10.3 => УТ 11 / КА 2 / ERP 2 (ЕРП 2) (документы, остатки и справочная информация из "1С:Управление торговлей, ред. 10.3" в УТ 11 / КА 2 / ERP 2). Обновлен до УТ 10.3.56.х, УТ 11.4.10.х, КА 2.4.10.х и ERP 2.4.10.х! Промо

Уже более 100 компаний приобрели перенос и выполнили переход на УТ 11 / КА 2 / ERP 2 с помощью нашей разработки! Обработка перехода с УТ 10.3 на УТ 11 / КА 2 / ERP 2 позволяет перенести не только остатки на указанную дату (как типовой перенос), но и все возможные документы за выбранный период. При выходе новых релизов этих программ оперативно выпускаем обновление обработки. Предоставляем техническую поддержку. Можем сделать бесплатный тестовый перенос!

29700 руб.

Как продать проект в 3 раза дороже и нанести клиенту пользу, выполнив не внедрение... 21

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

Практически все российские компании нуждаются не просто в установке 1С:ERP, 1С:Документооборота или какой-то другой программы, а в масштабных организационных изменениях, но мало кто из заказчиков это понимает. Те, кто занимается 1С, могут помочь бизнесу решить его проблемы, а заодно и продать проект внедрения в несколько раз дороже. Как это сделать, на конференции INFOSTART EVENT 2018 EDUCATION рассказал собственник и директор компании «Корада» Алексей Бояршинов.

27.05.2019    4756    cybrat    9       

Что важно, а что - срочно? 21

Статья no Нет файла Бесплатно (free) Управление проектом

Поговорим о приоритетах

20.05.2019    5013    1c-intelligence    16       

Онлайн-интенсив "Бизнес-процессы для подготовки к экзамену 1С:Специалист по платформе" 12 декабря 2019 г. Промо

На интенсиве будут рассмотрены все теоретические вопросы, связанные с устройством механизма бизнес-процессов – это необходимо для успешной сдачи экзамена 1С:Специалист по платформе. Также, в качестве практического примера, будет решена задача, аналогичная экзаменационной.

777 рублей

Устав писать Устав 31

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

Ответы на вопросы про то, нужен ли Устав для проектов автоматизации, и если нужен, то зачем?

06.05.2019    4560    MariaTemchina    8       

Программы для исполнения 488-ФЗ: Маркировка товаров Промо

1 января 2019 года вступил в силу ФЗ от 25.12.2018 № 488-ФЗ о единой информационной системе маркировки товаров с использованием контрольных (идентификационных) знаков, который позволяет проследить движение товара от производителя до конечного потребителя. Инфостарт предлагает подборку программ, связанных с применением 488-ФЗ и маркировкой товаров.

Как сжать время? 24

Статья no Нет файла 1С:Франчайзи, автоматизация бизнеса Бесплатно (free) Управление проектом Личная эффективность

Как, и зачем измерять задачи в чем-то, помимо часов.

04.05.2019    5511    1c-intelligence    39       

Путь джедая в управлении проектами 1С: умение быть, а не казаться 37

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

Чем руководитель проекта “на бумаге” отличается от “настоящего” руководителя проекта, умеющего направлять команду и выдавать ценный результат?

15.04.2019    7553    MariaTemchina    15       

Перенос документов, остатков и справочников КА 1.1 => КА 2 / УТ 11. Обновлено до КА 2.4.10.х и УТ 11.4.10.х! Промо

Более 130 компаний выполнили переход на КА 2 или УТ 11 с помощью нашей разработки! Позволяет перенести не только остатки и справочники (как типовая обработка), но и документы за нужный период времени. Предоставляем техподдержку, оперативно исправляем замечания, выпускаем обновления при выходе новых релизов программ 1С. Вы можете проверить разработку до покупки: сделаем бесплатный тестовый перенос из вашей базы КА 1.1 и предоставим доступ к базе-результату через веб-клиент!

29700 руб.

Стыд и Скрам, часть вторая 21

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

Крик души про иллюзию внедрения Agile. Продолжаем разговор про сложности, с которыми мы сталкиваемся, когда под видом гибких технологий используются "топорные" директивные методы. По сути, мы в очередной раз сталкиваемся с извечным конфликтом "сурового менеджмента" и "творческих разработчиков"

14.03.2019    8625    MariaTemchina    47       

Подборка решений для взаимодействия со ФГИС «Меркурий» Промо

С 1 июля 2019 года все компании, участвующие в обороте товаров животного происхождения, должны перейти на электронную ветеринарную сертификацию (ЭВС) через ФГИС «Меркурий». Инфостарт предлагает подборку программ, связанных с этим изменением.

20 мыслей об ИТ-проектах. Мысль №2. "С какой стороны подойти к новому проекту?" 38

Статья Руководитель проекта Нет файла Бесплатно (free) Управление проектом

Продолжаем серию статей из цикла “20 мыслей об ИТ-проектах”. Сегодня мы поговорим о том, с какой стороны подойти к новому проекту. Такой вопрос возникал у каждого, кому приходилось выступать в роли руководителя проектов, особенно первый раз. Да и для опытных РП некоторые проекты вызывают аналогичный вопрос.

13.02.2019    5147    chavalah    22       

Стыд и скрам - Чему нас учит Scream Guide 28

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

Название "Scream Guide" можно вольно перевести на русский как “Вопль ужаса от того, как Scrum применяют на практике”

12.02.2019    6682    MariaTemchina    20       

Очный семинар по регулярному менеджменту Александра Фридмана "Вы или Хаос", 12 декабря 2019 г. , Санкт-Петербург Промо

Семинар по регулярному менеджменту от Александра Фридмана для собственников, первых лиц и топов. Технология управленческого планирования, комплексного управления временем и другими ресурсами, выполнением поручений, делами, информацией, контактами (встречи-звонки-почта).

от 11000 до 29000 рублей

Бизнес, не горюй 34

Статья no Нет файла Бесплатно (free) Управление проектом

Про цели автоматизации.

04.02.2019    6394    1c-intelligence    64       

Лучший домик для поросенка, или Что нужно знать руководителю проекта внедрения 23

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

Тема управления проектами - популярная, вокруг нее много всего разного накручено. Кто-то считает, что главное - это выучить PMBOK и точно следовать правилам. Кто-то считает, что главное создать комфортную атмосферу, и сразу все как по волшебству заработает. В этой статье я попробую рассказать, какие шаги, по моему скромному мнению, нужно предпринять, чтобы начать более эффективно управлять проектами в организации.

31.01.2019    5497    MariaTemchina    0       

Перенос данных КА 1.1 => ERP 2 (ЕРП) (обработка переноса документов, остатков и справочной информации из "1С:Комплексная автоматизация, ред. 1.1" в "1С:ERP Управление предприятием, ред 2"). Обновлен до КА 1.1.115.х и ERP 2.4.10.х Промо

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

29700 руб.

Ошибки управленцев: как топ-менеджеров убивает перфекционизм 4

Статья no Нет файла Бесплатно (free) Управление проектом

В преддверии онлайн-конференции «Гнев и слезы руководителя» мы решили заранее познакомить нашу аудиторию со спикерами, причем сделать это через видео-истории. Начнем с видео-приглашения от Миланы Джиджоевой и ее виденья диджитализации рекрутинга в России.

24.01.2019    6906    user809424    11       

Что немцу хорошо, то русскому... Как минимум, небезынтересно. Продолжаем тему Канбан 32

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

Пользуясь несовпадением рождественских каникул в России и Германии, решила познакомиться с тем, как организована работа разработчиков в одном немецком банке. Сразу оговорюсь: еще давно, со времен совместных яхтенных плаваний с немцами, я противник четких стереотипов из серии "все русские всегда...." или "все немцы обязательно..." (пропущенные места предлагаю читателям заполнить самим в меру своей испорченности).

14.01.2019    7386    MariaTemchina    13