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

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

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

Мне понравился встретившийся на просторах интернета перевод английского слова 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 180 05.09.18 08:17 Сейчас в теме
что меня всегда восхищает в американцах - так это способность делать деньги из ничего , буквально из воздуха .
простую мысль " делите большие задачи на маленькие " назвать Agile , раскрутить это до некого подобия философии и даже " образа мышления ", используя при этом много красивых и непонятных слов

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

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

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

Да и сейчас, честно скажем, многие до сих пор впадают в ступор от предложений работать "по-гибкому": "как это в начале нет полного ТЗ? как это мы не знаем полную стоимость/функционал внедрения? как это постоянная тесная работа заказчиков с командой проекта?"
13. pro-rok 258 05.09.18 14:25 Сейчас в теме
(5) Мария, Вы все очень красиво описываете, да и я с Вами согласен, что это очень удобный и эффективный механизм, как бы его там не называли. Но теперь от Вас нужна статья "Как донести до клиента что нужно внедрять по гибкой технологии". Буквально сегодня от меня требовали стоимость внедрения ERP "под ключ" на основании двух страниц требований к системе. Как быть? Все вопросы одни и те же сколько нужно времени и денег? Предлагаю подготовить ТЗ-проект внедрения, без общей стоимости и рубля дать не хотят. А я им тут давай заливать гибкие технологии, частые поставки результатов, тесная работа.Не не катит.
CheBurator; +1 Ответить
23. MariaTemchina 1217 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 1217 06.09.18 08:39 Сейчас в теме
(29)
Редко бывает так, чтобы результат оказался совсем не нужен.
Поэтому чаще результат просто "дорабатывают напильником" до некоего работоспособного состояния.
Как минимум потому, что полный провал проекта по водопаду признавать не хочет никто, в том числе и "ответственные лица со стороны заказчика", на которых лежит значительная доля вины с точки зрения высшего руководства заказчика.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

- Друзья 2 последних разбившихся самолёта показали , что наша методика уменьшения турбулентности не сработала. Какие идеи?
-. Может крылья жёлтой краской покрасим.
Drivingblind; Gilev.Vyacheslav; MariaTemchina; +3 Ответить
19. Дмитрий Кузнецов 05.09.18 15:44 Сейчас в теме
(16) Для этого есть мат.моделирование, испытания в аэродинамической трубе, создание моделей и прототипов. И как правило, если выяснилось, что турбулентность выше расчетной, ни один конструктор не скажет - вот план, через 2 месяца найдем причину и устраним ее. Потому что ее, возможно нельзя устранить на данном этапе развития технологии. В принципе нельзя. Таких случаев в истории авиации тоже не мало.
57. strange2007 143 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 1217 05.09.18 13:30 Сейчас в теме
(10) Olga_aku - спасибо на тёплом слове.
15. andironenko 648 05.09.18 14:37 Сейчас в теме
У гибких (итеративных) методов работы есть один существенный минус - требуется некий специальный визионер, который видит картину целиком - и не с точки зрения текущего спринта, а с точки зрения того, к чему всё это должно прийти после завершения последнего спринта. И тут возникает концептуальная проблема - а мы не знаем какой у нас будет последний спринт. Мы плывем в потоке текущих задач - максимум что у нас есть - это бэклог, где есть какой общий список задач, но насколько он полон мы не знаем.

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

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

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

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

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

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

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

Как-то так...
45. andironenko 648 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 180 05.09.18 17:23 Сейчас в теме
(15)
Живой пример такого проекта - это работающая конфигурация 1С, после 2-3-4 лет эксплуатации, когда она дорабатывается силами своего отдела (такие доработки достаточно близки к идеологии Agile - работа идет небольшими циклами под конкретный запрос конкретного ЛПРа) - за редким исключением ситуация там характеризуется так - "Мы вот тут наворотили в процессе. Криво конечно получилось, сейчас бы сделали по другому, но сейчас проще новую программу поставить с нуля, чем делать на текущей".


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

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

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


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

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

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

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

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

Нюанс в том, что Agile - это не одна методика, а набор методик. Поэтому четкие границы провести сложно. Это, кстати, неплохо сделала компания 1С в описании одной конкретной методологии 1С:ТБР (технология быстрого результата), которая тоже относится к "семейству" Agile. Они прям SWOT-анализ провели с границами применения (кстати, видео-урок на эту тему лежит в открытом доступе). Там рекомендуют при помощи гибких методов реализовывать внедрения не предполагающие кардинальной переработки архитектуры.
51. andironenko 648 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 648 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 648 08.09.18 21:35 Сейчас в теме
(54) Здесь нет перехода на личность, здесь вопрос об опыте. Я бы с интересом пообщался с человеком, который имеет реальный опыт комплексной автоматизации предприятий на продуктах класса 1С:ERP с числом рабочих мест от 100. Это та комбинация (комплексность задачи, сложность программного решения, масштаб проекта), которая порождает определенные проблемы, которые в иных случаях просто не встречаются.
Поэтому я задал прямой вопрос - сколько у Вас таких проектов есть, какую часть из них Вы делали с использованием Agile, можно ли посетить одно из этих предприятий, чтобы пообщаться лично с пользователями. Если это действительно работающая практика, то я буду рад пропиарить этот опыт в сообществе - помочь в написании развёрнутой статьи с упором на те проблемы, которые не удаётся решить в водопаде и которые были решены с помощью гибких методов.
У меня действительно есть интерес к такому опыту. И не у одного меня, думаю.
Варианты: писали программу с нуля или внедряли простое решение или внедряли проект на 50 рабочих мест, к сожалению, не интересны - там нет таких проблем.
39. TODD22 18 06.09.18 12:59 Сейчас в теме
Году так в 2009 читал статью по разработке на 1с и там было описан метод "быстрого прототипирования", сделал документ, сделал форму, показал пользователю, получил обратную связь, доработал, показал пользователю, получил обратную снова доработал.... но тогда это модным словом "эйджаил" не называлось ещё....
А сейчас как верно заметили выше придумали очередную религию....

А термин эйджаил в каком году вошёл в обиход?
42. MariaTemchina 1217 06.09.18 20:47 Сейчас в теме
(39) Манифест Agile был написан, если мне не изменяет память, в 2001 году. А вообще все эти идеи гораздо старше, конечно. До работающих принципов разные умные люди часто додумываются независимо. Важно это всё описать и сделать возможной передачу опыта...
40. acanta 06.09.18 14:44 Сейчас в теме
Уже после "Смертельного марша - руководства по выживанию в безнадежных проектах". Т.е. сначала были проекты провалившиеся по каким-либо объективным причинам. После "разборов полетов" (который сам по себе не имеет смысла, без участников команды) и классификации причин провалов появились проекты безнадежные, в которых таковые причины наличествуют изначально в большой пропорции и участники проекта это осознают. Когда же проектанты научились выживать в условиях безнадежных проектов, встал вопрос о том, а не был ли возможен успех?
Аджайл это удовлетворение потребности человека в успехах, при в целом всеобщей безнадежности. Аджайл призван снизить требования и желания заказчиков до минимального допустимого уровня "на сейчас" и при этом как-нибудь не забыть о "потом".
Без глубокого понимания этой безнадежности, я бы даже сказала физического ощущения - невозможно почувствовать успех, поскольку на каждом отдельном этапе он действительно мизерный.
41. acanta 06.09.18 15:28 Сейчас в теме
Если потребность в успехе у клиента и у разработчика уже удовлетворены, то аджайл это не то что можно рекомендовать клиенту. Вариант, когда потребность в успехе удовлетворена только у одной из сторон, приводит к взаимному непониманию. Аджайл - выбор двух неудачников, которые стремятся к успеху.
43. MariaTemchina 1217 06.09.18 20:49 Сейчас в теме
(41) acanta - вот не люблю я такой категоричности "выбор двух неудачников"...
Не для всех ситуаций Agile подходит - согласна.
Если требования можно определить на старте и уровень технической определенности высокий - Agile тоже не нужен, согласна.
44. Infector 170 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)

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

24.01.2019    10085    user809424    11    

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

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

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

09.12.2020    1223    MariaTemchina    3    

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

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

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

03.12.2020    2666    MariaTemchina    7    

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

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

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

18.11.2020    2561    MariaTemchina    8    

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

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

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

29.06.2017    34986    1СERP    79    

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

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

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

11.09.2020    2977    alexandr.blinov    17    

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

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

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

04.09.2020    3221    MariaTemchina    23    

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

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

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

20.08.2020    3007    MariaTemchina    4    

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

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

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

09.06.2017    31409    1СERP    175    

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

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

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

26.06.2020    4526    1c-intelligence    17    

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

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

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

08.06.2020    5159    stepan96    12    

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

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

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

25.05.2020    5668    sapervodichka    1    

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

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

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

18.04.2017    32433    1СERP    189    

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

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

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

18.05.2020    11233    MariaTemchina    33    

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

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

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

23.03.2020    6078    MariaTemchina    24    

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

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

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

03.03.2020    6664    VLikhobabin    44    

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

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

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

10.04.2017    32443    1СERP    107    

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

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

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

23.01.2020    18372    MariaTemchina    8    

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

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

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

09.01.2020    7949    roman72    0    

Про одну Тётю

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

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

24.12.2019    6863    1c-intelligence    33    

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

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

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

03.04.2017    43469    1СERP    231    

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

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

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

14.10.2019    6039    chavalah    16    

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

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

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

19.09.2019    12716    ogroup    164    

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

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

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

16.09.2019    10156    GSoft    16    

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

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

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

23.02.2017    27889    Gavrik    10    

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

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

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

30.08.2019    13321    SergeyN    8    

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

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

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

20.08.2019    9223    Arsen1986    7    

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

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

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

28.06.2019    8472    SergeyN    1    

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

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

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

17.06.2016    40468    raiml    37    

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

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

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

24.06.2019    6921    sbase    9    

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

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

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

19.06.2019    10482    FB_10160810658600104    62    

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

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

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

18.06.2019    7814    MariaTemchina    8    

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

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

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

26.12.2014    45024    CheBurator    64    

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

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

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

31.05.2019    9937    MariaTemchina    23    

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

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

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

14.05.2019    11431    1c-intelligence    121    

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

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

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

06.05.2019    7985    MariaTemchina    8    

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

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

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

1 стартмани

14.09.2015    36467    axxell    15    

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

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

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

04.05.2019    9084    1c-intelligence    39    

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

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

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

15.04.2019    12227    MariaTemchina    15    

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

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

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

13.02.2019    8351    chavalah    22    

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

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

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

06.04.2015    37991    raiml    14    

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

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

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

12.02.2019    10541    MariaTemchina    20    

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

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

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

04.02.2019    10303    1c-intelligence    64    

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

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

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

31.01.2019    8424    MariaTemchina    0    

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

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

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

16.11.2014    28908    raiml    46    

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

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

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

14.01.2019    10418    MariaTemchina    13    

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

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

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

10.01.2019    13137    chavalah    123    

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

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

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

26.12.2018    10109    1c-intelligence    7    

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

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

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

13.11.2014    28106    raiml    236    

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

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

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

19.12.2018    10085    MariaTemchina    24    

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

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

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

09.12.2018    9358    chavalah    119    

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

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

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

05.12.2018    17363    andironenko    128