Что такое Agile mindset или, говоря по-русски, пронырливый образ мысли

Публикация № 898271 04.09.18

Управление - Управление проектом

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

Я начинаю серию статей, посвященных образу мысли Agile. Американский институт PMI, законодатель мировых стандартов по проектному управлению, наконец, заметил существование Agile – гибких методов управления проектами. И выпустил по этому поводу несколько руководств:

  • 6-ую версию PMBOK, где в каждом разделе рассказывается про методы и инструменты гибкой методологии управления проектами.
  • Введение в Agile – Agile Guide.
  • И книгу, направленную на создание в голове руководителей проектов того, что  PMI называет Agile mindset (гибкий образ мысли) – «PMI-ACP Exam Prep: A Course in a Book for Passing the PMI Agile Certified Practitioner (PMI-ACP) Exam». 

Коль скоро я со всей этой литературой, частично на русский язык не переведенной, внимательно ознакомилась, попробую выделить из нее самое ценное для читателей Инфостарта. Серия статей по Agile, которую я планирую здесь опубликовать, основана на двух вещах:

  • на идеях и предложениях от адептов проектного управления PMI, изложенных в вышеупомянутой литературе;
  • на практическом опыте приложения указанных выше идей и принципов к российским ИТ-проектам и проектам внедрения 1С, в частности.

 

Откуда вообще появился подход Agile? Почему нам приходится быть «пронырливыми»?

Майк Гриффитс, автор третьей из упомянутых в начале статьи книг PMI, выделяет следующие принципиальные различия между производственной работой (industrial work) и работой в информационной сфере (knowledge work):

Разные подходы к работе

 

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

 

12 принципов Agile-манифеста

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


1.      Самое важное – удовлетворить потребности заказчика, регулярно и непрерывно поставляя необходимые ему продукты.

Антипример: «Мы собрали с заказчика требования, полная ерунда, но это его проблемы – все зафиксировано в контракте, и к нам не может быть никаких претензий».
Пример Agile: «Совещаемся с заказчиком в процессе работы, уточняя при необходимости требования, демонстрируя промежуточный результат (лучше не в текстовом описании, а в  виде конкретных решений, которые можно "потрогать")».

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

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

3.      Разработчики и представители бизнеса должны ежедневно сотрудничать от начала до конца проекта.

Антипример: Без комментариев.
Пример Agile: Придумываем, как мотивировать представителей заказчика к постоянному участию в проекте. Универсального и простого решения тут быть не может, в моей практике работают: человеческие дружеские отношения, упоминание в контракте, налаженное расписание, распоряжения высшего руководства, завязка KPI заказчика на успех проекта, приглашение заказчика в ресторан (ваши варианты в комментариях).


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

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

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

Прокомментирую этот принцип в комплекте с еще одним, забегая вперед по списку: 

11.    Самые лучшие требования, архитектурные и технические решения рождаются у самоуправляемых команд.

Комментарий: PMBOK ссылается на концепцию X и Y Дугласа Макгрегора.
Макгрегор исследовал связь производительности труда работников с тем, насколько им передают ответственность. Часть менеджеров (их он назван руководители X), были уверены что: 

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

А другая часть менеджеров (руководители Y), напротив, считала что: 

  • труд — процесс естественный, если условия благоприятные, работники не просто примут на себя ответственность, но будут стремиться к ней;
  • если работники приобщены к организационным целям, они будут использовать самоуправление и самоконтроль;
  • приобщение является функцией вознаграждения, связанного с достижением цели;
  • способность к творческому решению проблем есть у многих, а интеллектуальный потенциал среднего человека используется лишь частично.

И, как нетрудно догадаться, производительность работников под началом менеджеров Y оказалась в итоге выше.  Исследования Макрегора проводились в 1960-х годах, с тех пор концепции мотивации неоднократно развивались и совершенствовались. Но общая идея осталась неизменной – людям важно, чтобы им доверяли и делегировали ответственность. 

Пример и антипример: Моя практика наблюдения за руководством проектами внедрения с точки зрения модели X и Y говорит о следующем: 

  • Инициативные и здравые сотрудники от «микроменеджмента» (то есть попытки руководить каждым их шагом) портятся и увольняются. Когда им даешь инициативу – система работает лучше. 
  • Бывает такое, что ленивые и бестолковые сотрудники, когда перестаешь их жестко контролировать, а предлагаешь проявлять инициативу, пытаются сесть на шею, то есть перестают что-либо делать. Для меня это, скорее, повод с сотрудником расстаться, чем переходить с модели Y на модель X. 

(Вообще, тема мотивации сотрудников/коллег/заинтересованных сторон – благодатная и бесконечная. Возможно, надо на эту тему написать отдельную статью с примерами удачных и провальных инструментов).

6.      Личное общение – самый эффективный и результативный способ обмена информацией как внутри команды, так и с окружающим миром.

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


7.     Самый верный показатель прогресса — работающий продукт.

Пример Agile: Если вы исправно выдаете работающий продукт в конце каждой итерации (или нескольких итераций), то это лучше всего позволяет победить страхи заказчиков вроде «за что мы им платим, если неизвестно, сколько это будет стоить».
Антипример: В проектах внедрения 1С очень часто множество небольших поставок невозможно. То есть в теории возможно, но никому не нужно – клиент все-равно будет работать со старым продуктом, пока какая-то критическая масса функционала не будет реализована. Часто в такой ситуации приходится применять так называемые гибридные методы – например, WaterScrumFall.

8.      Agile процессы настраивают на стабильный темп разработки, что дает возможность инвесторам, разработчикам и пользователям всегда работать в постоянном ритме.

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

9.      Постоянное внимание к повышению мастерства и хороший дизайн повышают гибкость проекта.

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

  • Потому что могут себе это позволить (а не находятся непрерывно в ситуации жесткого дедлайна, когда выдохнуть некогда, а все сроки сгорели еще вчера).
  • Потому что есть внешний контроль. Например, практика code review – анализа кода. Она требует больших затрат, ибо приходится работать двум людям там, где вполне может справиться один. Зато позволяет поймать больше багов сразу, повышает самодисциплину разработчиков, взаимозаменяемость специалистов. Люди, конечно, могут сами себя мотивировать хорошо работать, но когда кроме внутренних мотиваторов есть еще и внешние, то всё работает лучше. 
  • Потому что есть выстроенная система. Когда организация находится на начальном уровне зрелости, проект внедрения вытягивается в условиях ограниченного бюджета за счет титанических усилий разработчика и аналитика – тут не до грамотной архитектуры. 

10.    Простота – искусство воздержаться от лишней работы – основа Agile.


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

Как часто используются фичи?

Идея водопада заключается в том, чтобы реализовать все фичи единым махом (как нужные, так и не очень). Идея инкрементального управления проектом – что, в первую очередь, делаются те фичи, которые используются всегда и часто, и уже потом все остальные. Идея Agile в том, чтобы остановить проект после выполнения куска «всегда и часто», и переключиться на другие, более ценные проекты.

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

Комментарий: В этом месте как раз кроется один из способов отличить Agile от «Тяп-ляп». Это – наличие в команде рефлексии, что можно сделать лучше и где можно совершенствоваться. И применение итогов этой рефлексии на практике!

Антипример: А вот здесь я не буду приводить в качестве примера компанию, которая – ай-ай-ай – ничего не рефлексирует и не пытается повышать результативность. А наоборот, вспомню организацию, которая твердо решила, что у них должен быть Agile, и все по правилам, поэтому всю систему мотивации отменяем, жесткое руководство заменяем на самоуправление, диаграммы Ганта выбрасываем в мусорную корзину и т. п. Почему же это антипример, спросите вы?  Потому что попытка усовершенствовать все и сразу обречена на неуспех. Agile – это искусство двигаться небольшими шагами. Главное – в правильном направлении.

 

Коллеги, буду рада вашему опыту по теме. Каким образом в проектах внедрения получается проявлять «пронырливость»? Где не получается, а хотелось бы? Какими находками хочется поделиться?

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

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

Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. genayo 04.09.18 19:24 Сейчас в теме
Agile - это стильно, модно, молодёжно https://habr.com/post/422123/
2. pm74 217 05.09.18 08:17 Сейчас в теме
что меня всегда восхищает в американцах - так это способность делать деньги из ничего , буквально из воздуха .
простую мысль " делите большие задачи на маленькие " назвать Agile , раскрутить это до некого подобия философии и даже " образа мышления ", используя при этом много красивых и непонятных слов

зы. прошу пардона у адептов Agile , возможно я таки еще не дорос
LordKim; tormozit; Gilev.Vyacheslav; Aphanas; +4 Ответить
3. Сурикат 372 05.09.18 09:11 Сейчас в теме
(2)

Agile немного не про разбиение задач на маленькие.
Agile про то, когда мы задачи формулируем.

И сейчас возможно идеи, предложенные Agile, кажутся очевидными, но когда он появился это была небольшая революция.
MariaTemchina; +1 Ответить
5. MariaTemchina 1416 05.09.18 10:16 Сейчас в теме
(3)
И сейчас возможно идеи, предложенные Agile, кажутся очевидными, но когда он появился это была небольшая революция.

Да и сейчас, честно скажем, многие до сих пор впадают в ступор от предложений работать "по-гибкому": "как это в начале нет полного ТЗ? как это мы не знаем полную стоимость/функционал внедрения? как это постоянная тесная работа заказчиков с командой проекта?"
13. pro-rok 294 05.09.18 14:25 Сейчас в теме
(5) Мария, Вы все очень красиво описываете, да и я с Вами согласен, что это очень удобный и эффективный механизм, как бы его там не называли. Но теперь от Вас нужна статья "Как донести до клиента что нужно внедрять по гибкой технологии". Буквально сегодня от меня требовали стоимость внедрения ERP "под ключ" на основании двух страниц требований к системе. Как быть? Все вопросы одни и те же сколько нужно времени и денег? Предлагаю подготовить ТЗ-проект внедрения, без общей стоимости и рубля дать не хотят. А я им тут давай заливать гибкие технологии, частые поставки результатов, тесная работа.Не не катит.
CheBurator; +1 Ответить
23. MariaTemchina 1416 05.09.18 16:25 Сейчас в теме
(13)
Но теперь от Вас нужна статья "Как донести до клиента что нужно внедрять по гибкой технологии"


pro-rok - это тема, надо будет создать ))).

В двух словах, опыт мой и моих коллег:

- Заказчики бывают разные, но все хотят быстрый результат, поэтому можно прогнуть на гибкие методологии.
- После нескольких опытов проектов по Водопаду, когда результат оказался вообще не нужен, заказчики оказываются сговорчивее.
- Обещание сделать поставку с первым куском функционала позволяет замять тему "сколько будет стоить всё целиком".

Разумеется, не всех заказчиков можно убедить работать по такой схеме. Да и не всех нужно...
29. Крококот 06.09.18 05:51 Сейчас в теме
(23)
Заказчики бывают разные, но все хотят быстрый результат

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

После нескольких опытов проектов по Водопаду, когда результат оказался вообще не нужен, заказчики оказываются сговорчивее

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

Обещание сделать поставку с первым куском функционала позволяет замять тему "сколько будет стоить всё целиком"

"Меня терзают смутные сомнения" (с).
Во-первых, первый кусок функционала тоже не бесплатный (я правильно понимаю?), и о его цене, сроках и содержанию клиент будет живо интересоваться.
Во-вторых, не встречал я такого ни разу такого, чтобы руководство клиента интересовалось кусками функционала. И не слышал ни разу. Как-то все больше вопросы "а сколько будет стоить весь проект?".

Вообще ваши статьи для меня весьма интересны. Вы правильно описываете недостатки водопада и я с ними в общем и целом согласен.
Но вот agile... пока представляется мне в виде какой-то хрустальной мечты, которая не выдерживает столкновения с чугунным основанием реальности. Потому что непонятно где найти высококвалифицированных и высокомотивированных сотрудников (это я о пункте 11) и где найти всецело доверяющих тебе и платежеспособных клиентов.
CheBurator; +1 Ответить
31. genayo 06.09.18 08:20 Сейчас в теме
(29) Agile - это не про 1С. Вот и весь сказ.
34. Крококот 06.09.18 09:06 Сейчас в теме
(31)
Проблема в том, что водопад тоже подходит далеко не всегда. Претензии, высказываемые к нему вполне себе оправданы.
35. genayo 06.09.18 09:58 Сейчас в теме
32. MariaTemchina 1416 06.09.18 08:39 Сейчас в теме
(29)
Редко бывает так, чтобы результат оказался совсем не нужен.
Поэтому чаще результат просто "дорабатывают напильником" до некоего работоспособного состояния.
Как минимум потому, что полный провал проекта по водопаду признавать не хочет никто, в том числе и "ответственные лица со стороны заказчика", на которых лежит значительная доля вины с точки зрения высшего руководства заказчика.

Скажем так, полный провал внедренческих проектов по системам управления проектами, Workflow-системам и т. п. я, увы, видела. Когда внедряют, но не используют. Видела провал, когда 1С:УПП не получалось использовать для задач управленческого учета, только "для галочки" (из-за специфики бизнес-процессов заказчика). Формально результат проекта принят, но бизнес-ценности нет.
Во-первых, первый кусок функционала тоже не бесплатный (я правильно понимаю?), и о его цене, сроках и содержанию клиент будет живо интересоваться.

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

Во-вторых, не встречал я такого ни разу такого, чтобы руководство клиента интересовалось кусками функционала. И не слышал ни разу. Как-то все больше вопросы "а сколько будет стоить весь проект?".

В этом случае можно назвать полную сумму, а конкретный функционал, который туда войдет уточнять по ходу.
Или, другой вариант из моей практики - размытые границы окончания внедрения и сопровождения. То есть руководство готово к тому, что поддержка ERP-системы обходится в месяц в сумму в определенных пределах. И "допиливание" некритичного функционала в таком формате и происходит.
36. pro-rok 294 06.09.18 10:24 Сейчас в теме
(32)
В этом случае можно назвать полную сумму, а конкретный функционал, который туда войдет уточнять по ходу.
Можем промахнуться со стоимостью или необходимо в изначальную цену закладывать все возможные риски.
И "допиливание" некритичного функционала
с не критичным согласен, а как быть с критичным?.

Дано: предприятие. Цель: запустить ERP с января 2019.
Соответственно нужно к этому сроку выполнить:
проектирование по отдельности(Agile) или все сразу(Водопад)
доработки
Обучение персонала
Перенос данных
Тут все критично, можно конечно "мелочевку" скинуть на период эксплуатации, но и то не все. На подобных проектах весь некритичный функционал всегда относиться на "потом".

Мое личное мнение от водопада никуда не уйдем, слишком много предприятия в свое время обжигалось на проектах внедрения, которые растягивались на неопределенный срок и бюджет, и заканчивались как говорит автор ТЯП-ЛЯП. Собственник бизнеса или руководитель хочет четко понимать объем финансирования и результат в конце. И тут рождается мысль, а что если совместить водопад и Agile, может получиться как раз та модель которая необходима для нашей суровой реальности. Про это нужно статью написать, Мария, как Вы считаете?
4. MariaTemchina 1416 05.09.18 10:14 Сейчас в теме
(2)
что меня всегда восхищает в американцах - так это способность делать деньги из ничего ... используя при этом много красивых и непонятных слов

Да ладно, что вы всё про американцев! Наши тоже так умеют! Превратить какую-то идею в философию. Нашим даже проще - можно не придумывать красивые и непонятные слова, а взять из английского языка...
6. pm74 217 05.09.18 11:03 Сейчас в теме
(4)
взять из английского языка...
это обязательно . В английском одно слово зачастую и глагол и существительное и прилагательное , что очень удобно .

Agile software development - звучит красиво ,

Проворная разработка программ - ну , не очень ...

если выдумать новую методику , например когда нужно кодить стоя на голове , ее
лучше назвать Upside down software development
LordKim; Rain88; Vlad_2008; ducks01; MariaTemchina; +5 Ответить
7. Aphanas 89 05.09.18 11:04 Сейчас в теме
Остается только вопрос - кто за всё это заплатит?

Повысить результативность? Да легко! Хоть до космических пределов.
Ресурсов давайте побольше раз в сто.

ЗЫ: И времени.
8. MariaTemchina 1416 05.09.18 11:25 Сейчас в теме
(7)
Повысить результативность? Да легко! Хоть до космических пределов. Ресурсов давайте побольше раз в сто.

Если вы получите в сто раз больше ресурсов и сделаете больше в 50 раз - тут нельзя говорить про рост результативности ;-)))
9. sahn 05.09.18 12:10 Сейчас в теме
Все смешалось, кони, люди... Цели, задачи, реализация - в котел, добавить личных мотиваций по вкусу... Результат в тумане. Дао пути, реализация как суть, как процесс... Хочешь стать по настоящему богатым человеком - придумай религию... Слава Богу самолеты по методике Agile не строят, поскольку паровозы не летают. Если проект не укладывается в голове, не формализуется - то и не взлетает. Идя на поводу заказчика, его хотелок, диаметрально противополжных в подразделениях предприятия приходим к успешному внедрению? Сунь Цзы принесет больше результата, нежели Agile IMHO.
strange2007; Gilev.Vyacheslav; +2 Ответить
12. MariaTemchina 1416 05.09.18 13:37 Сейчас в теме
(9) /Ушла читать Сунь Цзы/ .

Если серьезно, то у Agile методов есть серьезные ограничения. Не надо строить самолет по методике Agile - в этом Вы, sahn, совершенно правы. Самолет нужно строить по водопаду (см. мою статью https://infostart.ru/public/871965/ ).
А вот, допустим, исследование по методам уменьшения турбулентности для самолета можно проводить по Agile. Предположили, попробовали, провели ретроспективу, попробовали еще раз и т. п.

Про хотелки - тоже всё непросто. Еще раз вспомню мысль про то, что очень часто "заказчик и пользователи считают, что знают, что именно им нужно до тех пор, пока вы не даете то, что они просили". Как раз при Agile, когда вы выдаете модель, прототип, кусочек с тем, что они заказывали - заказчики скорее осознают, что это не то, и сумеют к концу проекта одуматься и переформулировать требования. А в водопаде очень часто мы имеем записанные в ТЗ требования в формате "7 параллельных пересекающихся зеленых линий красного цвета", и никуда от них не уйдем.

P. S. А Сунь Цзы действительно надо будет почитать... Я с ним пока знакома только в переложении Владимира Тарасова, но уже понимаю, что сильный стратег...
16. pm74 217 05.09.18 14:42 Сейчас в теме
(12)[
А вот, допустим, исследование по методам уменьшения турбулентности для самолета можно проводить по Agile. Предположили, попробовали, провели ретроспективу, попробовали еще раз и т. п.

- Друзья 2 последних разбившихся самолёта показали , что наша методика уменьшения турбулентности не сработала. Какие идеи?
-. Может крылья жёлтой краской покрасим.
Drivingblind; Gilev.Vyacheslav; MariaTemchina; +3 Ответить
19. Дмитрий Кузнецов 05.09.18 15:44 Сейчас в теме
(16) Для этого есть мат.моделирование, испытания в аэродинамической трубе, создание моделей и прототипов. И как правило, если выяснилось, что турбулентность выше расчетной, ни один конструктор не скажет - вот план, через 2 месяца найдем причину и устраним ее. Потому что ее, возможно нельзя устранить на данном этапе развития технологии. В принципе нельзя. Таких случаев в истории авиации тоже не мало.
57. strange2007 145 24.10.18 09:13 Сейчас в теме
(12)
Как раз при Agile, когда вы выдаете модель, прототип, кусочек с тем, что они заказывали - заказчики скорее осознают, что это не то, и сумеют к концу проекта одуматься и переформулировать требования

Либо Вы откровенно не договариваете, либо предоставляете не совсем качественные услуги. Ведь именно поэтому заказчики часто недовольны, что франч сделал как просил заказчик, а потом долгие годы проблем и денежных потерь остаются с заказчиком.
Например, один из наикрутейших франчей, который получал от одной конторы огромные деньги ежемесячно, добавил уникальную кнопку на договоры, при нажатии на которую договор мог становиться либо с покупателем, либо с поставщиком. Всё по методикам (каким, не знаю и знать не хочу, хоть и рекламировали) - Штат бухгалтеров раздут (контролируют плавающие договора и контролёр за контролёрами), программистов орава, все работают, отчитываются результатах...
Ну? Вы ж понимаете, что так нельзя поступать? Вы поймите, это прописные истины и Вы их перечёркиваете: Заказчик никогда не признает ошибку, если от этого зависит голова на его плечах. Люди очень ленивы к изменениям и если привыкли с 1998 года так вести договоры, то и в 2008 году им тоже будет так привычней. Неужели Вы не знаете основу этих познаний заказчика??? Да на любом предприятии есть один или несколько зазнаек, которые точно уверены, что у них уникальные в стране (в мире) бизнес-процессы и только они являются обладателями этих знаний. Это же основы основ всех автоматизаций!
Нет, конечно же это мой хлеб - исправлять предприятия после горе-автоматизаторов, но мне же обидно за нас, за программистов. Эх... агля всё больше и больше отталкивает.
14. Дмитрий Кузнецов 05.09.18 14:32 Сейчас в теме
(9) В общем-то, самолеты строили и по Agile. Возьмите историю любого массового боевого самолет второй мировой войны, увидите все это - постоянное изменение требований, расширение функционала, необходимость частых поставок новых модификаций, тесную работу с заказчиком. Неплохо получалось в общем-то. По водопаду тоже строили много чего. Хрестоматийный XB-70 например, или сверхзвуковые пассажирские, судьба которых не впечатляет.
27. 🅵🅾️🆇 05.09.18 18:33 Сейчас в теме
(9) Почти всегда веду разработку в одиночку и по agile. На небольших проектах пока вы получите техзадание, мой пользователь уже будет вовсю использовать готовый продукт.

Да, с минимум документации (а она и не нужна, если есть всего 1 кнопка: "сделать хорошо"), да кое-где с довольно велосипедно-костыльной реализацией, зато получит то, что ему надо, а не то что хотел. И получит гораздо быстрее, приложив минимум усилий (пару раз пощупать, дать фидбэк на словах).
38. acanta 06.09.18 12:22 Сейчас в теме
(27) по agile клиент получает не то что ему надо, а то, на что хватает времени и сил у него и у разработчика.
В водопаде - на что хватает денег.
В этих подходах используются разные виды ресурсов, точнее человекоемкость аджайла выше чем материалоемкость/фондоемкость.
Единственный мотив заказчика в пользу аджайла- когда внимание специалистов стоит дешевле чем готовое оборудование с готовой документацией и плановым обучением. Аджайл - это инструмент (проект исследования) для разработки водопада(стандарта), который получат следующие клиенты в следующих проектах. Успех заказчика в аджайл - это побочный эффект, а не цель. Если проект привел к привел к вырождению аджайл в тяп-ляп значит неправильно определены спринты.
10. Olga_aku 05.09.18 13:25 Сейчас в теме
Статья понравилась. Спасибо.
MariaTemchina; +1 Ответить
11. MariaTemchina 1416 05.09.18 13:30 Сейчас в теме
(10) Olga_aku - спасибо на тёплом слове.
15. andironenko 739 05.09.18 14:37 Сейчас в теме
У гибких (итеративных) методов работы есть один существенный минус - требуется некий специальный визионер, который видит картину целиком - и не с точки зрения текущего спринта, а с точки зрения того, к чему всё это должно прийти после завершения последнего спринта. И тут возникает концептуальная проблема - а мы не знаем какой у нас будет последний спринт. Мы плывем в потоке текущих задач - максимум что у нас есть - это бэклог, где есть какой общий список задач, но насколько он полон мы не знаем.

То есть тактически Agile великолепен, но совершенно не гарантирует качественного решения в итоге проекта. Живой пример такого проекта - это работающая конфигурация 1С, после 2-3-4 лет эксплуатации, когда она дорабатывается силами своего отдела (такие доработки достаточно близки к идеологии Agile - работа идет небольшими циклами под конкретный запрос конкретного ЛПРа) - за редким исключением ситуация там характеризуется так - "Мы вот тут наворотили в процессе. Криво конечно получилось, сейчас бы сделали по другому, но сейчас проще новую программу поставить с нуля, чем делать на текущей".

Вторая критическая проблема - это продажа таких проектов заказчику при работе в подрядной организации. Заказчики хотят фиксированную стоимость проекта +/- допустимые колебания. Agile этого совершенно не гарантирует.
CheBurator; Gilev.Vyacheslav; +2 Ответить
17. MariaTemchina 1416 05.09.18 15:26 Сейчас в теме
(15)
У гибких (итеративных) методов работы есть один существенный минус - требуется некий специальный визионер, который видит картину целиком

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

То есть тактически Agile великолепен, но совершенно не гарантирует качественного решения в итоге проекта.

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

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

Это проблема, да. Большинство франчайзи, успешно или не успешно пытающиеся внедрять Agile говорят о том, что это сложно. А те, кому удается, отвечают обычно примерно следующее: "Заказчик хочет видеть фиксированную стоимость, но после провала нескольких проектов по водопаду, когда он получает абсолютно ненужный ему результат, скрипя сердце соглашается на Agile".

Как-то так...
45. andironenko 739 07.09.18 11:05 Сейчас в теме
(17)
нам нужен не только при работе по Agile, но и при работе по любой методологии, включая водопад

Водопадная методология на первом этапе предполагает постановку задач и их консолидацию в итоговые функциональные требования к системе и чем детальнее требования, тем лучше. Эти требования затем декомпозируются на конкретные работы по автоматизации и можно контролировать как решение конкретной задачи, так и прогресс по проекту в целом.
Для Agile итоговые требования более декларативны - большее значение имеют ситуативные предпочтения. Понятно что и то и то - декларация о намерениях, всё зависит от конкретного исполнителя, но в водопаде хотя бы нужно стараться так делать, в Scrum этого не требуется даже в теории - если ошибаюсь, поправьте - опишите какие методологии Agile содержат конкретные метрики, которые увязывают результаты текущего спринта с прогрессом по всему проекту в целом. Было бы очень интересно.

Скажем, 1С рекомендует применять гибкую методологию 1С:ТБР (технология быстрого результата) только для более-менее типовых внедрений


Вот тут я не соглашусь с 1С.Типовые решения лучше внедрять по Waterfall (со скидкой на реальность), а вот не типовое решение зачастую лучше идет по Scrum - потому что реально тяжело описать детальные требования к системе, которой еще нет. Тут и раннее прототипирование очень даже помогает - прежде чем писать код, лучше "видеть" как это выглядит, и рефакторинг кода по итогам готовности каких-то функциональных блоков очень даже помогает и парное программирование и пр. инструменты Agile.

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


Старая истина - лучше всего проект внедряет "вторая" команда. Накопленный опыт ошибок в рамках первых попыток - это бесценный опыт - тут уже и заказчик знает что он хочет и сам он гораздо более сговорчив и ставит реалистичные цели. У нас в Раздолье ситуация обратная - много обращений от тех кто внедрял 1С:ERP с использованием гибких методик и где ситуация зашла в тупик - вроде бы всё было хорошо в процессе, но бюджет съели, а систему так и не запустили в эксплуатацию. Задают вопрос - что делать? Мы вынуждены предлагать собирать новый бюджет и звать нас.
50. Vladimir Litvinenko 07.09.18 19:56 Сейчас в теме
(45)
а систему так и не запустили в эксплуатацию

Все таки Agile - это набор ценностей и принципов, а не методик и методов, применяемых на практике. Применять можно наборы инструментов, например Scrum или Kanban. И их применение требует соблюдения определенных правил. Даже если "ценность людей выше чем ценность процессов и документации" и люди вдруг потребовали отказаться от правил ))

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

Если 2 недели мало для создания жизнеспособного продукта - можно сделать итерацию длинной до 4 недель. Как бы такая продолжительность ни пугала. Особенно если альтернатива - "спринт" длинной в полгода )) Если же проект разогнался, инкременты стабильны и бизнес требует релизиться чаще - переходим на 2-ух недельные или даже 1-недельные спринты. Хотя это потребует больших управленческих затрат - управленческие инструменты, в основном планирование, приходится применять с большей частотой.


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


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


"Although implementing only parts of Scrum is possible, the result is not Scrum. Scrum exists only in its entirety and functions well as a container for other techniques, methodologies, and practices." - напутствие от авторов ))


Да, подготовка продукта к тому чтобы он был работоспособен и готов к релизу в конце каждой итерации - это дополнительные затраты ресурсов. Его надо всесторонне протестировать к концу каждого спринта, подготовить поставку для релиза в виде cf- или setup- файла. И здесь не получится просто "ускориться в 4 раза". Это плата за снижение рисков и готовность инкремента к релизу. Скорость же затем можно вернуть за счет применения DevOps практик, которые к сожалению в 1С пока слабо развиты.

И конечно, если команда (в смысле бизнеса, а не группы разработчиков) не готова отказаться от идеи оторвать два колеса от автомобиля, или ставит целью исключительно увеличение скорости, а не снижения рисков за счет готовности каждого инкремента к релизу, то лучше просчитанный на полгода вперед водопадный подход. В нем может выручить высокая квалификация специалистов в команде разработки и большой опыт аналогичных крупных проектов.
55. acanta 08.09.18 20:32 Сейчас в теме
(50)
А потом как снег на голову оказывается, что проект на новой итерации "неожиданно" потребовал навыков, которых пока нет. "Неожиданно пришла зима".

Вы правы. Причина провала всегда одна - у команды нет компетенций, необходимых для следующего спринта.
26. pm74 217 05.09.18 17:23 Сейчас в теме
(15)
Живой пример такого проекта - это работающая конфигурация 1С, после 2-3-4 лет эксплуатации, когда она дорабатывается силами своего отдела (такие доработки достаточно близки к идеологии Agile - работа идет небольшими циклами под конкретный запрос конкретного ЛПРа) - за редким исключением ситуация там характеризуется так - "Мы вот тут наворотили в процессе. Криво конечно получилось, сейчас бы сделали по другому, но сейчас проще новую программу поставить с нуля, чем делать на текущей".


Абсолютно " в точку". Я еще называю это лоскутной разработкой. Тут пришили , здесь прилепили . В итоге получается "кафтан" почти полностью сделанный из лоскутков , который трудно перекраивать , но зато он сидит по размеру и часто имеет оригинальный фасон.
18. Дмитрий Кузнецов 05.09.18 15:38 Сейчас в теме
Когда мы говорим, что "Agile великолепен, но совершенно не гарантирует качественного решения в итоге проекта", имеем ли мы в виду что он не гарантирует решения "В СРАВНЕНИИ С" другими методологиями? Есть ведь известная фраза про демократию, которая не гарантирует качественного управления (но все остальные режимы не гарантируют его как минимум в такой же степени). Насколько реально предсказуемой оказывается работа по водопадному методу, если смотреть постфактум?

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

Может быть, в популярности водопада гораздо больше социально-психологических причин? Легче продать заказчику проект по водопадной модели, а потом в случае выхода за рамки обосновать его (особенно если заказчик меняет требования сам - "вы сами видите, теперь надо переделывать"), чем изначально сказать - один Бог знает, сколько это займет все (пусть это и будет правда).
Vladimir Litvinenko; MariaTemchina; +2 Ответить
46. andironenko 739 07.09.18 11:08 Сейчас в теме
(18)
етодологии применяются к разным ситуациям. При тех уровнях неопределенности, где работают гибкие методологии, водопад не то что был бы дольше или дороже - он был бы невозможен, как невозможно плавать в пустом бассейне. Это тоже может сказываться на качестве сравнения - в


Для ответа на эти вопросы написал эту статью https://infostart.ru/public/898904/
20. Fragster 1116 05.09.18 15:55 Сейчас в теме
22. MariaTemchina 1416 05.09.18 16:07 Сейчас в теме
(20) Он рядом с 5-ым, я их вместе комментировала.
21. herfis 462 05.09.18 16:05 Сейчас в теме
Смотрю на этот цикл статей и на другие подобные статьи в интернете - имя им легион.
Все правильно, все солидно, все взвешенно и - абсолютно бесполезно.
Ну да - объясняются концепции, если человек вообще ничего про это не слышал.
Но смех в том, что эти концепции можно разъяснить несколькими матерными предложениями. Все остальное - мишура по большей части. Чего сильно не хватает - так это реального практического "мяса".
Деталей хода реальных проектов и описание деталей действий и взаимодействий реальных команд.
Типа "и тут заказчик нам ТЫДЫЩЬ! Бегу к канбану и плачу...". Вот такое я почитал бы.
CheBurator; MariaTemchina; +2 Ответить
24. MariaTemchina 1416 05.09.18 16:30 Сейчас в теме
(21) Вообще, и в этой, и в предыдущих статьях, я стараюсь приводить конкретные примеры конкретных внедрений (максимально деперсонифицированные, ибо не хочется ничего лишнего озвучивать)...

Может быть, стоит их описывать более жизненным языком, чтобы было "ТЫДЫЩЬ!" ?...
25. herfis 462 05.09.18 16:41 Сейчас в теме
37. Сурикат 372 06.09.18 10:54 Сейчас в теме
(21)
Для практических демонстрации практического примера в большинстве своем нанимают же консультантов.
Вы же наверняка свои знания тоже не за бесплатно предоставляете?
28. Gilev.Vyacheslav 1900 05.09.18 21:47 Сейчас в теме
все больше убеждаюсь что Agile это религия, и не более того
вы еще дом постройте или операцию больному проведите

прям вижу - больной, какой еще наркоз, а кто согласовывать будет, вот тут разрез побольше сделать?...
30. sahn 06.09.18 07:24 Сейчас в теме
Мария молодец, написала статью, мы почитали, подискутировали. В очередной раз порадовались за буржуинов, эк они красивую обертку в очередной раз создали и ее плодотворно продают. Молодцы. В целом, попытка подтянуть любое внедрение под одну методику, мало перспективно. Модель системы с обратной связью, насколько отличается от парадигмы agile? А применять когда? Каковы граничные условия и ресурсы для выбора данной конкретной методики? Мне лично, этого не хватило в статье. Хорошее описание, вырванное из контекста, попытка обобщения в рамках одной статьи. Все хорошо, но чуть - чуть чего то не хватает... Перчика?. Нет. Исходных данных. Как то так. Ждем продолжения...
33. MariaTemchina 1416 06.09.18 08:44 Сейчас в теме
(30)
Модель системы с обратной связью, насколько отличается от парадигмы agile?

Об этом я писала в первой статье. Система с обратной связью, где одна поставка - это итеративная модель. Система с обратной связью где много небольших поставок - это Agile.
https://infostart.ru/public/871965/

А применять когда? Каковы граничные условия и ресурсы для выбора данной конкретной методики?

Нюанс в том, что Agile - это не одна методика, а набор методик. Поэтому четкие границы провести сложно. Это, кстати, неплохо сделала компания 1С в описании одной конкретной методологии 1С:ТБР (технология быстрого результата), которая тоже относится к "семейству" Agile. Они прям SWOT-анализ провели с границами применения (кстати, видео-урок на эту тему лежит в открытом доступе). Там рекомендуют при помощи гибких методов реализовывать внедрения не предполагающие кардинальной переработки архитектуры.
51. andironenko 739 08.09.18 00:26 Сейчас в теме
(30) можно что-то полезное сделать.
(50) А Вы когда такое пишите «в следующий спринт запустить оприходование и реализацию» складывается ощущение что Вы глубокий теоретик.
Вы как будете поддерживать систему где на складе что-то только появляется и исчезает - а где заказы? А что будете делать со взаиморасчетами? Вы в следующий спринт будете чистить регистры от левых движений? Перепривязывать накладные к заказам?
Не боитесь что пользователи побьют за обезьянью работу? А если их (пользователей) пара сотен?
(50)
52. Vladimir Litvinenko 08.09.18 01:29 Сейчас в теме
(51)

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


Хм. Например в ERP, УТ 11 заказы включаются и отключаются функциональной опцией. Система изначально предполагает возможность работать без заказов и включать их при внедрении позаказного учета, если он будет необходим. Точно также как возможность включения ордерного учета и потребность в нем на складах не означает необходимости немедленно включать его при внедрении.

Иначе продолжая эту цепочку можно сказать "Реализации, поступления и заказы!? А где же коммерческие предложения и сделки? Вы потом будете привязывать заказы к сделкам?". "А где ордерный учет, вы потом будете связывать ПТУ и ордера?" И так можно до бесконечности пока не будут включены все функциональные опции в ERP ))

Вовсе нет. При старте позаказного учета можно начать этот учет с новых документов. И ордерный учет можно запускать не с начала учета. Разумеется об этом нужно заранее предупредить заказчика и в качестве альтернативы предложить в первых инкрементах выдать цепочку "Заказ поставщику - Поступление - Реализация - Оплата". Для этого и водопадная модель и итеративная предлагают свои инструменты.


Вообще это слабо относится к теме. Просто показался некорректным пример с заказами, со взаиморасчетами более корректен. Речь изначально шла о том, что в Ваших примерах команды, внедрявшие системы, не выдавали работоспособных инкрементов, исходя из слов
не запустили в эксплуатацию

И это главный признак того, что они не работали в рамках фреймворка и не применяли его. Итеративный подход конечно может привести к лоскутной автоматизации и костылям. Но это при любой модели может быть, зависит как принятие технических решений построено. BPR как раз минимизирует риск этого. Вот только неработоспособных инкрементов быть не должно. Все же нельзя обвинять машину в том, что она не работает, если ей открутили колеса и сняли двигатель ))
MariaTemchina; +1 Ответить
53. andironenko 739 08.09.18 10:10 Сейчас в теме
(30) можно что-то полезное сделать.
(50) А Вы когда такое пишите «в следующий спринт запустить оприходование и реализацию» складывается ощущение что Вы глубокий теоретик.
Вы как будете поддерживать систему где на складе что-то только появляется и исчезает - а где заказы? А что будете делать со взаиморасчетами? Вы в следующий спринт будете чистить регистры от левых движений? Перепривязывать накладные к заказам?
Не боитесь что пользователи побьют за обезьянью работу? А если их (пользователей) пара сотен?
(52)

Сколько в Вашей практике успешно выполненных проектов с числом пользователей более 100 человек?
54. Vladimir Litvinenko 08.09.18 13:39 Сейчас в теме
(53) Ушел считать и думать как мерянье "у кого больше" и переход на личности относится к вопросу о корректности примеров с командами, которые не работали в рамках фреймворка и не соблюдали его требования, и выводов о неработоспособности подхода на основе этого ))

Напомню, что изначально некоторые ребята также изначально водопад закидали, что сейчас часто приводится как самый яркий пример опасностей водопада. Хотя там проблема не в водопаде, а незаинтересованности участников проекта, эффекте "второй команды внедрения" и большей склонности заказчика к сотрудничеству после первых неудач : Sentinel Project: 5 Lessons Learned
56. andironenko 739 08.09.18 21:35 Сейчас в теме
(54) Здесь нет перехода на личность, здесь вопрос об опыте. Я бы с интересом пообщался с человеком, который имеет реальный опыт комплексной автоматизации предприятий на продуктах класса 1С:ERP с числом рабочих мест от 100. Это та комбинация (комплексность задачи, сложность программного решения, масштаб проекта), которая порождает определенные проблемы, которые в иных случаях просто не встречаются.
Поэтому я задал прямой вопрос - сколько у Вас таких проектов есть, какую часть из них Вы делали с использованием Agile, можно ли посетить одно из этих предприятий, чтобы пообщаться лично с пользователями. Если это действительно работающая практика, то я буду рад пропиарить этот опыт в сообществе - помочь в написании развёрнутой статьи с упором на те проблемы, которые не удаётся решить в водопаде и которые были решены с помощью гибких методов.
У меня действительно есть интерес к такому опыту. И не у одного меня, думаю.
Варианты: писали программу с нуля или внедряли простое решение или внедряли проект на 50 рабочих мест, к сожалению, не интересны - там нет таких проблем.
39. TODD22 18 06.09.18 12:59 Сейчас в теме
Году так в 2009 читал статью по разработке на 1с и там было описан метод "быстрого прототипирования", сделал документ, сделал форму, показал пользователю, получил обратную связь, доработал, показал пользователю, получил обратную снова доработал.... но тогда это модным словом "эйджаил" не называлось ещё....
А сейчас как верно заметили выше придумали очередную религию....

А термин эйджаил в каком году вошёл в обиход?
42. MariaTemchina 1416 06.09.18 20:47 Сейчас в теме
(39) Манифест Agile был написан, если мне не изменяет память, в 2001 году. А вообще все эти идеи гораздо старше, конечно. До работающих принципов разные умные люди часто додумываются независимо. Важно это всё описать и сделать возможной передачу опыта...
40. acanta 06.09.18 14:44 Сейчас в теме
Уже после "Смертельного марша - руководства по выживанию в безнадежных проектах". Т.е. сначала были проекты провалившиеся по каким-либо объективным причинам. После "разборов полетов" (который сам по себе не имеет смысла, без участников команды) и классификации причин провалов появились проекты безнадежные, в которых таковые причины наличествуют изначально в большой пропорции и участники проекта это осознают. Когда же проектанты научились выживать в условиях безнадежных проектов, встал вопрос о том, а не был ли возможен успех?
Аджайл это удовлетворение потребности человека в успехах, при в целом всеобщей безнадежности. Аджайл призван снизить требования и желания заказчиков до минимального допустимого уровня "на сейчас" и при этом как-нибудь не забыть о "потом".
Без глубокого понимания этой безнадежности, я бы даже сказала физического ощущения - невозможно почувствовать успех, поскольку на каждом отдельном этапе он действительно мизерный.
41. acanta 06.09.18 15:28 Сейчас в теме
Если потребность в успехе у клиента и у разработчика уже удовлетворены, то аджайл это не то что можно рекомендовать клиенту. Вариант, когда потребность в успехе удовлетворена только у одной из сторон, приводит к взаимному непониманию. Аджайл - выбор двух неудачников, которые стремятся к успеху.
43. MariaTemchina 1416 06.09.18 20:49 Сейчас в теме
(41) acanta - вот не люблю я такой категоричности "выбор двух неудачников"...
Не для всех ситуаций Agile подходит - согласна.
Если требования можно определить на старте и уровень технической определенности высокий - Agile тоже не нужен, согласна.
44. Infector 196 07.09.18 09:55 Сейчас в теме
47. acanta 07.09.18 12:45 Сейчас в теме
Т.е.все рекомендации сводятся к одному- не показывать одному исполнителю весь бюджет проекта, а на каждое очередное внедрение "под ключ" выделять максимум половину (или треть или четверть).
48. alex-l19041 8 07.09.18 16:51 Сейчас в теме
Идея Agile в том, чтобы остановить проект после выполнения куска «всегда и часто», и переключиться на другие, более ценные проекты.
- не понятно, "переключиться" - совсем? а остальное доделывать?
49. acanta 07.09.18 17:09 Сейчас в теме
Конечно! обязательно доделывать, но только "потом", когда договорная цена на эти доделки поднимется выше любого альтернативного проекта. Из принципа 80/20 можно предположить что в очередной проект включается 20% текущих задач. Это при условии что бэклог проекта обновляется. Следующий проект - 20% из актуального бэклога, которые декомпозируем на спринты и т.д.
Идея водопада - не допустить повышения цен на доделки, доделывание или исправление ошибок всегда бесплатное. Таким образом пик затрат у разработчика в водопаде приходится на окончание проекта.
58. user1124189 06.01.19 22:46 Сейчас в теме
Когда работал в консалтинговой компании, левая колонка весила процентов тридцать, правая - 70. Перешел в самозанятый режим - и левая колонка обнулилась, 100% - в правой.
Оставьте свое сообщение

См. также

ТРИЗ. Решение нерешаемых проблем в бизнесе Промо

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

Советскую теорию решения изобретательских задач давно применяют крупнейшие мировые корпорации, причем не только в технологической области, но и в сфере бизнеса. На конференции Infostart Event 2021 Post-Apocalypse основатель бизнес-клуба ТРИЗ Алексей Благих рассказал, как с помощью ТРИЗ решать нерешаемые задачи, и почему метод проб и ошибок здесь не поможет.

09.11.2022    1393    user1576201    6    

Тест для самопроверки руководителя проекта: как отличить падавана от рыцаря-джедая?

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

Многое узнать ты еще можешь, мой старый падаван. Это только начало… Если честно, каждый раз, когда мне предлагают поднять тему “компетенций руководителя проекта”, у меня возникает ощущение, что я все время бьюсь в одну и ту же стену.

12.01.2023    2165    MariaTemchina    28    

На что похож ваш продукт: на Аквариум или на Муравейник? 

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

Давайте поиграем в метафоры в лучших традициях экстремального программирования. А заодно проведем новогодний конкурс - на лучшую метафору для автоматизированного продукта

27.12.2022    1491    MariaTemchina    28    

Как донести здравый смысл до заказчика. Инструменты архитектора

Управление проектом Анализ и проектирование ИТ-систем Бесплатно (free) Бесплатно (free)

Андрей Овсянкин на конференции Infostart Event 2021 Post-Apocalypse поделился инструментами, которые помогают ему обрабатывать большой поток задач и экономить недели на обсуждении проекта. Он рассказал, как искать ошибки в процессах, какие диаграммы полезны при общении с заказчиком и с помощью каких инструментов можно быстро рисовать наглядные картинки вместо долгих разговоров.

05.08.2022    8309    Evil Beaver    16    

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

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

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

16.09.2019    14592    GSoft    21    

Технология вялых проектов

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

Не все ж такие молодцы.

11.05.2022    4384    1c-intelligence    49    

Документальное оформление бизнес-процессов в проектах по автоматизации

Анализ и проектирование ИТ-систем Управление проектом Внедрение ИТ-системы Бесплатно (free) Бесплатно (free)

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

02.02.2022    6615    denisgalimoff    3    

7-ой PMBOK® Guide: Есть ли там что-то действительно полезное?..

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

Честно скажу, я всегда с некоторой настороженностью открываю разные "чересчур умные" книжки. Особенно их переиздания (в данном случае аж 7-ая версия). Ибо очень часто разрыв между высокими концепциями и реальностью оказывается чересчур огромным (особенно в этом плане меня позабавил катастрофический непонятный вебинар на тему понимания).

07.09.2021    8150    MariaTemchina    0    

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

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

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

24.01.2019    11329    user809424    11    

Новый PMBoK 7®: Неужели заговор его составителей против простых людей все-таки раскрыт?

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

Некоторое время назад один из моих читателей в своем письме предположил, что есть настоящий заговор у тех, кто пропагандирует изучение PMBoK®.

30.07.2021    8405    MariaTemchina    13    

Как приручить драконов. История построения экосистемы на основе 1С

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

Многие задачи интеграции и мониторинга не имеют стандартных решений в среде 1С. О том, как команда 1С-ников смогла организовать успешный симбиоз учетной системы и системы тысяч внешних устройств, на INFOSTART MEETUP Новосибирск.Online рассказал TeamLead и специалист по внедрению компании ИнфоСофт Григорий Шатров.

14.05.2021    4366    G.Shatrov    6    

Пришиваем хвост: нужен ли Эджайл в 1С или глупости это всё?..

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

Коллеги, приглашаем поучаствовать в опросе - Agile в проектах внедрения 1С: реально работает или это миф? Интересен практический опыт!..

12.03.2021    7502    MariaTemchina    86    

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

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

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

09.06.2017    33940    1СERP    175    

9 советов, как уговорить девушку. Точнее, как уговорить Заказчика работать по Agile, когда он этого не хочет

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

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

16.02.2021    4276    MariaTemchina    45    

Как бороться с соблазном объять необъятное, или Канбан-система в проектах 1С

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

На первом онлайн-митапе в Санкт-Петербурге Мария Темчина рассказала участникам митапа о принципах работы Канбан-системы в проектах 1С. Как выбрать инструмент для работы по Канбану, с чего начать при внедрении, и какие игры помогут освоить эту систему.

12.02.2021    4518    MariaTemchina    17    

Как умирают розовые единороги, или бизнес-автоматизация как способ сделать людей несчастными

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

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

10.02.2021    6001    andironenko    15    

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

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

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

18.04.2017    35488    1СERP    189    

Статья Компетенции РП по версии PMI и здравому смыслу. Часть 2-ая

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

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

09.12.2020    2819    MariaTemchina    3    

Что почитать про Agile для чайников?

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

Продолжаю рубрику “Письма в редакцию”. Ко мне иногда обращаются с вопросом - вот, я, мол, совсем не представляю, что такое Agile…

03.12.2020    5972    MariaTemchina    9    

Компетенции руководителя проекта: по версии PMI и здравому смыслу. Часть 1-ая.

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

Об компетенции руководителя проекта сломано немало копий (хорошо, если не об самих руководителей).  В этой статье хочу оставить свои пять копеек, отталкиваясь от тех компетенций, которые институт PMI® - законодатель моды мирового проектного управления - озвучил в качестве требований к сертификации PMP® со 2-ого января 2021 года.

18.11.2020    7045    MariaTemchina    9    

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

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

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

10.04.2017    35556    1СERP    107    

Как создать коробочный программный продукт

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

Создание коробочного продукта – процесс нелегкий и долгий. Помочь разработчикам, которые только начинают свой путь в этом направлении, решил Сергей Сорокин – основатель компании MoscowSoft, которая входит в топ-3 компаний-продавцов коммерческих продуктов на Инфостарте. Сергей рассказал, как выбрать и протестировать идею, объяснил, стоит ли бросать наемную работу ради собственной разработки, и поделился опытом, как Инфостарт помогает при продвижении продукта и в борьбе с пиратами.

05.10.2020    4162    primat    2    

Стыд и Скрам: взгляд глазами собственника из IT-шников

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

Не все, кто употребляют понятия Agile и Scrum, понимают, что они означают. О том, насколько в реальном мире автоматизации бизнеса на платформе 1С применимы гибкие подходы к разработке ИТ-продуктов на конференции Infostart Event 2019 рассказал основатель и соучредитель группы компаний WiseAdvice Иван Тягунов.

18.09.2020    5413    IvanAT1981    5    

Советы начинающим РП: Подводим итоги шляпной вечеринки 

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

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

15.09.2020    3230    MariaTemchina    5    

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

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

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

03.04.2017    46864    1СERP    234    

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

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

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

11.09.2020    4247    alexandr.blinov    17    

Как продвигать авторские конфигурации 1С

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

Конфигурации 1С продвигать на рынке самостоятельно нелегко. Мало того, что нужно развивать продукт, чтобы удовлетворять потребности клиентов и выгодно отличаться от конкурентов, нужно еще заниматься его популяризацией, продажами и поиском проектов для внедрений. Большую часть этой работы готов взять на себя Инфостарт. Авторам останется только разработка, развитие и внедрение. Чем именно готов помочь Инфостарт, рассказал руководитель корпоративного отдела компании Рамин Курбанов. 

07.09.2020    3122    RKurbanov    3    

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

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

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

04.09.2020    4914    MariaTemchina    30    

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

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

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

17.06.2016    42280    raiml    37    

Матрица СКГ как инструмент разработки деловой модели

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

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

24.07.2020    3339    Soliton    10    

Видеозаписи открытых вебинаров Марии Темчиной

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

В этой публикации решила собрать здесь видеозаписи открытых вебинаров с моим участием. Чтобы были в одном месте, ибо их не всегда просто найти на Инфостарте. "Всё, что вы хотели узнать...", "Лучшие морковки проектов внедрения...", "Путь джедая в управлении проектами..." и так далее.

21.07.2020    4136    MariaTemchina    1    

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

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

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

26.06.2020    5609    1c-intelligence    17    

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

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

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

26.12.2014    47378    CheBurator    66    

Наиболее типичные ошибки при оценке работ в проектах 1С

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

Для кого эта статья? Если вы руководитель проектов (РП) с опытом «от трех проектов», то можете не читать: скорее всего, ничего нового вы не узнаете. А если вы хотите стать РП в проектах 1С или вы профессионал (разработчик, аналитик, консультант), к которому часто обращаются за оценкой, то вам будет полезно узнать о типичных ошибках при оценке. Если вам необходимо реализовать задачу, которую не имеет смысла делать по классической проектной технологии, но заказчик требует фиксированной оценки, и задача на 2-5 человеко-месяцев, - то вам будет полезно понять методы оценки работ. Если читатель часто пользуется услугами удаленных разработчиков/аналитиков, то вам, возможно, станет понятно, почему «человек все сделал, мы ему заплатили, сколько сказал, а он от нас ушел и больше работать не хочет». Типичные ошибки распределю по классам.

13.06.2020    3468    Koder_Line    9    

Как воспитать в себе РП? Часть 2. Растим ведущего руководителя проектов

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

Теперь поговорим про роль ведущего руководителя проектов, задающего и формирующего политику управления проектами в компании.

08.06.2020    8076    MariaTemchina    0    

Как воспитать в себе РП? Часть 1

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

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

01.06.2020    9215    MariaTemchina    4    

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

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

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

1 стартмани

14.09.2015    37597    axxell    15    

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

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

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

25.05.2020    7062    sapervodichka    1    

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

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

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

18.05.2020    13525    MariaTemchina    34    

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

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

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

23.03.2020    8118    MariaTemchina    26    

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

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

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

13.11.2014    28784    raiml    236    

Визуализация фич Vanessa Automation в StoryMapper

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

Описан процесс визуального упорядочивания коллекции feature-файлов в виде карты пользовательских историй. Используется инструмент гибкого управления требованиями StoryMapper.

21.03.2020    4944    oleynik.dv    7    

Как завершать проекты в срок

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

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

10.03.2020    5668    VLikhobabin    6    

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

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

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

03.03.2020    10267    VLikhobabin    44    

CVP - анализ как инструмент принятия управленческих решений Промо

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

В данной статье хотелось бы акцентировать внимание читателей, которым близка тема управленческого учета, на вопросах CVP – анализа («затраты-объем-прибыль») и маржинального учета.

13.05.2014    140980    Evgen.Ponomarenko    5    

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

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

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

23.01.2020    45474    MariaTemchina    12    

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

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

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

04.01.2020    7137    capitan    52    

Как продавать, не продавая? Сарафан для 1с-ника Промо

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

Измышления на тему управляемого запуска сарафанного радио и создания очереди клиентов в применении к сфере 1с-услуг.

27.10.2013    54453    nurpoz    157    

BDDSM-практики, или 50 оттенков желтого

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

В статье описаны практические результаты применения методики BDDSM на отдельно взятом РЕАЛЬНОМ проекте поддержки.

26.12.2019    12995    Mistress_A    28    

Про одну Тётю

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

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

24.12.2019    7653    1c-intelligence    33    

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

Управление проектом Анализ и проектирование ИТ-систем Бесплатно (free) Бесплатно (free)

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

14.10.2019    6601    chavalah    16