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

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

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

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

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

 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

См. также

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

Управление проектом Бесплатно (free)

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

24.01.2019    9806    user809424    11    

Как стать исполнителем в проекте от Инфостарта

Управление командой Управление проектом Бесплатно (free)

Инфостарт в поисках специалистов, которые готовы взяться за реализацию интересных проектов. Как подать заявку и стать исполнителем, с кем согласна сотрудничать компания и на каких условиях, рассказал руководитель проектов корпоративного отдела Инфостарта Александр Блинов.

11.09.2020    1923    alexandr.blinov    17    

Давайте спасем древесных осьминогов или 12 советов для начинающих РП от опытных товарищей

Управление проектом Бесплатно (free)

Ниже я попыталась собрать житейские советы от опытных руководителей проектов 1С и выпускников курсов по управлению ИТ-проектами на Инфостарте с моими комментариями. 

04.09.2020    2447    MariaTemchina    22    

Что делать, если с поддержкой 1С всё горит или несколько слов про ITSM…

Управление услугами и сервисом Управление бизнес-процессами (BPM) Управление прочее Управление проектом Бесплатно (free)

Проекты - это, конечно, важно, с завершением проекта внедрения, жизнь прикладного решения, на самом деле, только начинается. И самое интересное еще только впереди… Не случайно в Agile все чаще говорят о “гибком управлении продуктом”, а вовсе не только “проектом”.

20.08.2020    2310    MariaTemchina    4    

Проблемы внедрения 1С:ERP на крупном предприятии Промо

Управление проектом Бесплатно (free)

В ходе публикации предыдущих статей о проектной технологии ВЦ «Раздолье» и системе мотивации в фирме-франчайзи 1С, читатели попросили поделиться опытом реальных проектов, поскольку парадные рапорты о нескончаемых успехах всех утомили и не несут пользы для профессионалов. Мы попросили руководителей проектов ВЦ «Раздолье» поделиться такой непростой информацией. И сейчас представляем Вашему вниманию очередную статью по этой теме. Автор – Пикурен Вера – руководитель проектов ВЦ «Раздолье».

29.06.2017    34265    1СERP    79    

Управление в стиле Догвилль

О жизни Управление проектом Бесплатно (free)

Как и почему жизнь на работе становится всё хуже. Или всё лучше.

26.06.2020    4141    1c-intelligence    15    

Есть ли жизнь после внедрения, или упрощаем работу в сопровождении

Управление проектом Бесплатно (free)

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

08.06.2020    4693    stepan96    12    

Добрый великан

Управление проектом Бесплатно (free)

Руководители проектов определяют наше настоящее, каким оно будет?! Ответ прост - таким, каким и сам РП.

25.05.2020    5275    sapervodichka    1    

История одного неуспешного проекта Промо

Управление проектом Бесплатно (free)

В ходе публикации предыдущих статей о проектной технологии ВЦ «Раздолье» и системе мотивации в фирме-франчайзи 1С, читатели попросили поделиться опытом неуспешных проектов, поскольку парадные рапорты о нескончаемых успехах всех утомили и не несут пользы для профессионалов. Мы попросили руководителей проектов ВЦ «Раздолье» поделиться такой непростой информацией. И сейчас представляем Вашему вниманию первую статью по этой теме. Автор – Пикурен Вера – руководитель проектов ВЦ «Раздолье».

09.06.2017    31002    1СERP    175    

Почему Scrum не работает в проектах 1С

Управление проектом Agile (XP, SCRUM, Канбан) Бесплатно (free)

Более точная формулировка заголовка, пожалуй будет такой -  Почему Scrum в чистом виде плохо работает в проектах внедрения продуктов 1С.

18.05.2020    10596    MariaTemchina    33    

Кто здесь? Или как проводить онлайн-совещания

Управление проектом Управление командой Бесплатно (free)

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

23.03.2020    5519    MariaTemchina    24    

4 причины, почему проекты никогда не завершаются в срок

Управление проектом Бесплатно (free)

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

03.03.2020    6102    VLikhobabin    44    

Такие разные франчайзи. Часть вторая: Особенности реализации крупных проектов, Глава 1. О людях Промо

Управление проектом Бесплатно (free)

Продолжаем публикацию цикла статей о бизнесе франчайзи 1С. В предыдущих статьях мы рассказали о наиболее распространенном мнении о фирмах франчайзи 1С, об истории развития франчайзинга. Поставили вопрос о выборе системы мотивации. Предыдущие публикации вызвали оживленное обсуждение. В продолжении темы расскажем о том – как выглядит работа проектного подразделения фирмы-франчайзи. Расскажем на примере проектного офиса ВЦ «Раздолье». Предложим обсудить проблемы, с которыми приходится сталкиваться в проектном бизнесе. Автор статьи Андрей Мироненко.

18.04.2017    31875    1СERP    189    

7-ой PMBoK - конец классического проектного управления? Часть 1-ая

Управление проектом Waterflow Бесплатно (free)

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

23.01.2020    13717    MariaTemchina    8    

1С СППР, как инструмент по внедрению, разработке и сопровождению информационных систем

СППР Управление проектом Бесплатно (free)

Система проектирования прикладных решений (СППР) – инструмент от фирмы «1С», который позволяет проектировать конфигурации, вести по ним полную документацию в разрезе объектов системы, собирать требования на реализацию и выдавать на их основе детально описанные задачи программистам. Как правильно использовать СППР при работе с многосоставной командой, на конференции Infostart Event 2019 Inception рассказал генеральный директор компании «Иритум» Роман Кальмансон.

09.01.2020    6518    roman72    0    

Про одну Тётю

Управление проектом Бесплатно (free)

Суровое челябинское распределение ресурсов

24.12.2019    6652    1c-intelligence    32    

Такие разные франчайзи, или как мы делаем большие проекты на 1С. Часть первая: ты помнишь, как всё начиналось Промо

Управление проектом Бесплатно (free)

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

10.04.2017    31875    1СERP    107    

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

Управление проектом Бесплатно (free)

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

14.10.2019    5948    chavalah    16    

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

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

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

19.09.2019    12206    ogroup    163    

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

Управление проектом Бесплатно (free)

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

16.09.2019    9608    GSoft    15    

Мотивация персонала в фирмах франчайзи: а она работает? Промо

Управление проектом Бесплатно (free)

Думаем, что практически любого работающего человека интересует вопрос мотивации. Этой проблемой в одинаковой степени озабочены работники и работодатели: как мотивировать людей, сколько платить, как платить, какая часть оплаты должна быть фиксированной, а какая зависеть от результата работы, как это всё повлияет на результаты работы, стоит ли быть строгим и дотошным руководителем или нужно активно делегировать полномочия подчиненным. ВЦ "Раздолье" провело небольшое исследование на тему мотивации и вот его результат. Автор статьи Андрей Мироненко.

03.04.2017    42631    1СERP    231    

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

Управление проектом СППР Бесплатно (free)

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

30.08.2019    11825    SergeyN    7    

Эволюция пользовательской документации 1С в производственной компании

Пользователю системы Управление проектом Бесплатно (free)

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

20.08.2019    8761    Arsen1986    7    

Быстрый старт: минимальный набор автоматизации типовых процессов

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

Автоматизация дает множество преимуществ бизнесу, но в то же время ее выгода может быть настолько несущественной, что процесс принесет компании больше убытков, чем прибыли. С чего начать эффективную автоматизацию, какие процессы стоит автоматизировать на первом этапе, а какие – лучше оставить на потом, рассказала руководитель разработки систем учета компании «Едадил» Екатерина Золотарева.

16.08.2019    8276    Hissin    18    

Про спагетти, или как исследовать бизнес-процессы организации Промо

Техническое задание Управление бизнес-процессами (BPM) Управление проектом Бесплатно (free)

Многие руководители предприятий не обладают полной картиной происходящего в собственных производственных подразделениях. Они знакомы с организационной структурой, направлениями деятельности, общими экономическими показателями. Если по результату получилась прибыль, то наступает уверенность успеха. Но есть ли на рынке предприятия, которые длительное время удерживаются в "слепом" режиме управления?

23.02.2017    27564    Gavrik    10    

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

Управление проектом Финансовый учет и бюджетирование (FRP) Финансовый учет и бюджетирование (FRP) УУ Бесплатно (free)

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

28.06.2019    7992    SergeyN    1    

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

Управление проектом Бесплатно (free)

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

24.06.2019    6743    sbase    9    

Цифровая трансформация. Будущее учетных систем

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

О цифровой трансформации слышали все, но немногие в этом разбираются. Что она собой представляет, какие несет изменения, на что надо обратить внимание айтишникам и 1С-никам, рассказал на конференции руководитель департамента автоматизации строительных организаций компании «Первый БИТ» Иван Аверьянов.

19.06.2019    10184    FB_10160810658600104    62    

10 способов злоупотребления сотрудниками своим служебным положением и методы борьбы с ними с помощью учетной системы Промо

Управление проектом Бесплатно (free)

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

17.06.2016    40126    raiml    37    

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

Управление проектом Бесплатно (free)

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

18.06.2019    7542    MariaTemchina    8    

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

Управление проектом Бесплатно (free)

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

31.05.2019    9018    MariaTemchina    23    

Как мы со Стасом завод за 2 месяца автоматизировали

Управление проектом Бесплатно (free)

Мой опыт быстрого внедрения.

14.05.2019    11164    1c-intelligence    121    

Практические вопросы внедрения и развития автоматизации склада Промо

Управление проектом Бесплатно (free)

Мне, как одинэснику, не приходилось заниматься какими-то узкими задачами «от сих до сих». Вся моя профессиональная деятельность, как одинэсника, была всегда связана с очень широким кругом вопросов. Наверное, потому, что я работал, в основном, в малых компаниях, где приходилось работать над всем спектром вопросов.

26.12.2014    44629    CheBurator    64    

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

Управление проектом Бесплатно (free)

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

06.05.2019    7556    MariaTemchina    8    

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

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

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

04.05.2019    8965    1c-intelligence    39    

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

Управление проектом Бесплатно (free)

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

15.04.2019    11662    MariaTemchina    15    

Практика пуска склада продуктов питания Промо

Бухгалтерский учет Управление проектом Оптовая торговля, дистрибуция, логистика 1С:Франчайзи, автоматизация бизнеса Бесплатно (free)

Описывается опыт пуска склада (охлажденная и замороженная продукция) с точки зрения IT. Со временем из складского подразделения была создана компания, которая оказывает логистические услуги (3PL-оператор) сторонним Клиентам.

1 стартмани

14.09.2015    36262    axxell    15    

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

Управление проектом Бесплатно (free)

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

13.02.2019    8228    chavalah    22    

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

Управление проектом Agile (XP, SCRUM, Канбан) Бесплатно (free)

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

12.02.2019    9988    MariaTemchina    20    

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

Управление проектом Бесплатно (free)

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

04.02.2019    10078    1c-intelligence    64    

Как теряют бизнес. Реальные истории от бизнес-консультанта. Промо

Управление бизнес-процессами (BPM) Управление проектом Бесплатно (free)

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

06.04.2015    37733    raiml    14    

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

Управление проектом Бесплатно (free)

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

31.01.2019    8326    MariaTemchina    0    

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

Управление проектом Бесплатно (free)

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

14.01.2019    10133    MariaTemchina    13    

20 мыслей об ИТ-проектах. Мысль №1. "О незаменимых людях"

Управление проектом Бесплатно (free)

Этой статьей начинается цикл из 20-ти обещанных мыслей об ИТ-проектах. Надеюсь, что по прочтении кто-то посмотрит на проблему незаменимых людей с другой стороны.

10.01.2019    12835    chavalah    123    

Внедрение программного продукта. Особенности работы бизнес-консультанта. Часть II Промо

Управление проектом Бесплатно (free)

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

16.11.2014    28763    raiml    46    

Где мы взяли флакон?

Управление бизнес-процессами (BPM) Управление проектом Бесплатно (free)

История появления и развития методики

26.12.2018    9835    1c-intelligence    7    

Озарение после прочтения макулатуры по проектному управлению

Управление проектом Бесплатно (free)

Открываю этой публикацией мини-рубрику "Письма в редакцию". По мотивам очередной статьи на Инфостарте пришло мне письмо на корпоративную почту. Прямо-таки, крик души. С разрешения автора, решила опубликовать публичный ответ. Ибо согласна с автором письма, пишущим: "Я уверен, что не я один такой убогий, кто задается подобного рода "идиотскими" вопросами, но при этом почему-то все молчат, видимо, pmbok с agile-ом поистине творят чудеса молчания..."

19.12.2018    9813    MariaTemchina    24    

20 мыслей об ИТ-проектах, или 20 лет спустя.

Управление проектом Бесплатно (free)

В этой серии из 20-ти статей я готов поделиться своей практикой управления проектами. Примеры, опыт и только то, что проверено лично. Выбираем темы голосованием!

09.12.2018    9175    chavalah    119    

Бизнес-консультант в малом и среднем-бизнесе. Кто это и зачем он нужен? Промо

Управление проектом УУ Бесплатно (free)

Я не буду здесь давать сухие определения, думаю, они никому не интересны. Бизнес-консультант – это тот самый человек, которого приглашают со стороны, чтобы он помог найти решение каких-то проблем. Также очевидно, что взгляд «со стороны» очень часто помогает выявить то, что вы никогда не обнаружите, будучи сотрудником компании. Я хочу с вами поговорить исключительно о бизнес-консультантах, которые работают с малым и средним бизнесом, т.к. с предприятиями с численностью сотрудников ориентировочно от 5 до 70 человек. Эта работа во многом отличается от того, что делают специалисты, которых привлекают в подобных случаях крупные компании. И, как раз, с этими нюансами есть смысл разобраться.

13.11.2014    27967    raiml    236    

Памятка руководителя: не играйте с деньгами

Управление проектом Личная эффективность Управление персоналом (HRM) Бесплатно (free)

Важная статья о персонале из цикла «Памятка руководителя»: здесь я планирую затронуть один из наиболее острых вопросов – деньги. А также развернуто ответить на некоторые комментарий читателей по двум прошлым статьям.

05.12.2018    17055    andironenko    128    

Шаг назад и ... шаг назад (классификация внутренних проектов)

Управление проектом Бесплатно (free)

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

03.12.2018    8714    capitan    26    

Белая и пушистая рецензия на Чёрную книгу Скрам

Управление проектом Бесплатно (free)

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

26.11.2018    10147    MariaTemchina    40