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

03.12.18

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

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

Краткое содержание первой серии - в ней рассказывалось о ведении проектов методом роевого интеллекта (Swarm intelligence).

Роевой интеллект (Swarm intelligence) как метод управления проектами (анти-утопия)

Не совсем буря, но волна народного гнева смела в комментариях хрупкие мостки логики. И основной посыл был: хотим работать в Agile!
Тучи начинали сгущаться над головой великого комбинатора.

— Одну минуточку, — сказал Остап, чарующе улыбаясь, — маленькая заминка.

Тут очнувшийся Ипполит Матвеевич, разбрызгивая слюну, ворвался в разговор.

— Позвольте! — завопил он. — Почему комиссионный сбор? Мы ничего не знаем о таком сборе! Надо предупреждать. Я отказываюсь платить эти тридцать рублей!

— Хорошо, — сказала барышня кротко, — я сейчас все устрою.

Итак, вернемся на шаг назад и приступим к классификации внутренних проектов.

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

Классическая форма тройственной ограниченности (впоследствии в нее добавили еще парочку ограничений, но название оставили прежним)

 

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

 

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

 

1. Начнем с апологетов Agile, чтобы отпустить их пораньше.
Ну и просто по алфавиту.

Попытка вести все проекты по Agile подозрительно напоминает "кукурузные времена" Хрущевской оттепели. Ну не вырастет кукуруза на вечной мерзлоте, а там, где условия есть - самое милое дело.

Собственно сам Agile это лишь манифест, методы ведения проекта могут быть Scrum, Lean software development, Extreme programming, Kanban, но все они предполагают гибкость разработки и некоторую некомпетентность заказчика.
Кстати, пытливые умы обратят внимание на некоторый факт.
Канбан празднует свой 60 летний юбилей. В былые годы он был бы уже на пенсии, а сейчас благодаря нашему правительству пользуется привилегиями предпенсионера.
Программированию тоже немало лет. И вот эти две жабы два одиночества встретились. Откуда взялся расцвет и мировая популярность в столь преклонном возрасте? Ответ прост - доткомы. Именно веб разработка дала такой толчок гибким методам программирования.
И в них (этих методах) гораздо больше от отделов продаж, чем от программистов.
Программисты то всегда люди конкретные, это у продажников 2х2 может быть равно и 3 и 5, а если прикрыть двери то и 6.
На профильных сайтах то тут то там появляются статьи как ужасен Scrum. Тот же Хабр переполнен статьями о возврате к подробным тех. заданиям.
Это не ностальгия, а нормальный ход истории. Мода на гибкую разработку проходит.
Лопнет ли этот пузырь Scrum, как лопнули доткомы, как взлетал и падал биткоин, мы увидим в ближайшее время.
Скорее всего он займет свою нишу и продолжит спокойное существование. А пока:

Если неопределенность невелика, а команда проекта ну просто коллектив единомышленников, то это типично Agile случай.

Берите лучшие практики и вперед. Как я уже говорил, ничего нового в них нет. Любой прораб вам расскажет про Scrum больше, чем самый продвинутый евангелист Agile. Утром летучка, вечером доклады, днем сплю в прорабской. А про Канбан к слову - пенсионеры и те, кто застал времена дефицита. У них на уровне инстинктов эта схема работает - купил три пакета гречки, остался последний - надо снова уходить на промысел (значит россияне придумали канбан, а никакие не японцы, ну вы понимаете). А вот апологеты гибкого программирования моей компании, всегда притаскивают только один пакет сахара в каморку программистов и из-за этого потом буквально до следующего похода сосут лапу.

Раз уж зашла речь о временах СССР, то от Agile
2. переходим к Waterfall.

Он кстати в реалиях 1С возможно еще более распространен.

Это многочисленные ФЗ-ххх, изменения ставок НДС, форм отчетности т.п.
Когда неопределенность равна нулю, а полномочия велики, заинтересованность участников не имеет значения, спокойно обведите в календаре даты. Все сработает.

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

Старый добрый Waterfall. Те, кто могут себе это позволить, наигравшись с Agile возвращаются в его лоно с удовольствием.

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

 

Иначе мы попадаем в

3. проект типа штурмовщина.

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

Во времена того же СССР была очень распространена пословица: "Чтобы корова давала больше молока и меньше ела - ее надо меньше кормить и больше доить."

При откровенно слабом, но непомерно влюбленном в себя руководстве подход именно такой.

Это самый тяжелый и к сожалению самый распространенный метод ведения проекта.

Собственно, и вести его вам нужно как корабль среди штормового моря.

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

Рядом с этим типом проектов, очень рядом находится

4. проект типа «показуха».

Отличается от предыдущего он только тем, что заинтересованность команды равна нулю и ничем не увеличивается кроме лозунгов.

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

"Заменим всех бухгалтеров роботами!", "Применим ИИ к водителям погрузчиков!" ,"Каждой продаже по блокчейну!" 

Высшему руководству как елей на душу сравнение компании с Газпромом, на худой конец со Сбербанком.
(Как тут опять не вспомнить великого комбинатора и Нью-Васюки)

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

Именно в этот момент появляются разнообразные канбан доски, скрам митинги и все остальное.

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

Это ведь машина не для езды, а для гордости.

И обычно тут же находится тип проекта, когда и неопределенность - 100%

5. Это «сказочные» проекты. От слов "пойди туда не знаю куда, принеси то не знаю, что..." разумеется

"Даешь цифровизацию!","Перейдем планирование по схеме Бойля-Мариотта", "Телепортацию в каждый отдел!".

Чего только начальники непрофильных отделов не прочитают ВКонтакте и не пообещают на совещаниях.

Ведущего такой проект наилучшим образом описал Ходжа Насреддин в истории об осле и падишахе.
Даже добавлять особенно нечего. Запрашивайте финансирование, вычерчивайте графики выполнения к 2025 году. Стоп. Эта дата уже зарезервирована правительством. Тогда к 2026 году.

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

В длительной перспективе, последние три варианта - бесперспективны.

Как говорил один очень уважаемый мной кадровик: «Когда компания работает в режиме вечного аврала, остаются те, кому на все наплевать».

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

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

6. В моей классификации – тупиковые.
Пример: вы автоматизируете работу сотрудника, который, что называется ловил рыбку в мутной воде. Завышал тарифы, брал откаты, усушка, утруска и т.п.

В более мягком варианте просто борется за свое право смотреть котиков в инстаграмме.

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

От меня рекомендаций не ждите.

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

 

И только сейчас, на точке до которой половина и не дочитала, мы пришли к проектам, к которым

7. применим роевой интеллект.

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

То, о чем была прошлая статья.

У роевого интеллекта, к слову, так же, как и у Agile есть достаточно большое количество методов реализации.

Самые распространенные из них три :
7.а  Метод роя частиц
Его отличительные особенности выражаясь языком плаката:
– Все агенты должны избегать пересечения с окружающими их агентам;

– Каждая частица должна корректировать свою скорость в соответствии со скоростями окружающих её частиц;

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

Области применения: Биоинженерия, биомеханика, биохимия; Задачи машинного обучения; Задачи оптимизации функций многих параметров и топологий; Область проектирования.
В проектах программирования это скорее задачи оптимизации и автоматизации понятной рутинной работы пользователей.
7.б  Муравьиный алгоритм (самый известный и применяемый в решении различных прикладных задач, классика - Задача коммивояжёра)

Концепция алгоритма заключается в способности муравьев находить кратчайший путь крайне быстро и адаптироваться к различным внешним условиям. При движении каждый муравей помечает свой путь феромоном, что в дальнейшем используется другими муравьями. Это и есть простой алгоритм одного агента, который в сумме всех агентов колонии позволяет находить кратчайший путь или изменять его при обнаружении препятствия.
Преимущества данного метода:  Достаточно эффективен для TSP (Traveling Salesman Problem) с небольшим количеством узлов; Используется приложениях, которые могут адаптироваться к изменениям; Благодаря памяти всей колонии и случайному выбору пути не так сильно подвержен неудачным первоначальным решениям.
Области применения: Расчеты компьютерных и телекоммуникационных сетей; Задача коммивояжёра; Задача раскраски графа; Задача оптимизации сетевых трафиков.
В проектах программирования это задачи выбора из различных вариантов решения, когда возможны варианты тестовой эксплуатации

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

Математический аппарат я с общего разрешения приводить не буду.

Хотя некоторые формулы очень приятны глазу, например: 

vZ77;v+rnd()(Pbest-x)c1+rnd()(gbest-x)c2

или 
.
 

О графиках я вообще молчу

.

.

В статьях о Канбан я тоже не наблюдал формул Сигео Синго и Ясухиро Мондена.

Заинтересовавшиеся могут легко найти всю доступную информацию в сети.

 

 

Вполне возможно, что кто-то дополнит или полностью отринет мою классификацию проектов.

Это можно сделать в комментариях.

 

Статья не призвана никого обидеть. 

Все события и герои вымышлены. Любые совпадения с реальными личностями случайны.

Завершить же ее я хотел бы очень известной цитатой:


Господи, дай мне спокойствие принять то, чего я не могу изменить, дай мне мужество изменить то, что я могу изменить. И дай мне мудрость отличить одно от другого

        Молитва немецкого богослова Карла Фридриха Этингера (1702— 1782).

 

Разбирайтесь с вектором сил перед тем, как настроить паруса проекта.
.

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

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

Я из того поколения, для которого друг это человек, который поделится с тобой своим запасом воздуха, это немного отличается от "ставящий лайки"

Agile управление проектами канбан

См. также

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

Кейсы проектов Бесплатно (free)

Как определить, что риск проекта высок настолько, что взяться за него – в 99% случаев значит потерять драгоценное время, деньги и другие ресурсы? Как еще до старта определить, что проект в лучшем случае на выходе станет пародией на задуманное, а в худшем – будет сорван? Сформулируем список типовых рисков срывов проекта и постараемся уберечь от ошибок внедренцев и заказчиков.

20.12.2023    2734    0    1СERP    21    

31

Внедрение крупного проекта на ERP 2.5 с применением методических решений из УПП 1.3 и обеспечением товаров с разных складов с учетом серий

Кейсы проектов Платформа 1С v8.3 1С:ERP Управление предприятием 2 Оптовая торговля, дистрибуция, логистика Россия Бесплатно (free)

В 2021 году начали проект в дистрибьюторской компании. Имели большой опыт внедрения УПП, но периодически возникали вопросы. Зачем что-то придумали в ERP, что стало менее удобнее, чем было в УПП? Почему нельзя было взять лучшие идеи из УПП и ERP и скрестить их? А идея, что обеспечение нужно выносить из заказов, с каждым новым проектом находила все большее подтверждение. В итоге на этом проекте удалось применить лучшие (на мой взгляд) методические решения, которые мне довелось внедрять в конфигурациях УПП и ERP, в т.ч. подход, что реагировать нужно только на важное (то, как на заре появления ERP Фирма 1С ее позиционировала).

05.07.2023    14232    0    ASchekachev    37    

55

Организация работы внутренней команды 1С с помощью Канбан

Канбан и поставка ценности Бесплатно (free)

Когда ИТ-отдел разрывается между разнотипными задачами от внутренних заказчиков, стоит посмотреть в сторону гибких подходов. О том, как, используя три практики Канбана – WiP-лимит, визуализация и распределение по сервисам – улучшить отношения с заказчиками, не бояться давать обещания по срокам и укладываться в них, на конференции Infostart Event 2021 Moscow Premiere рассказал руководитель направления 1С в компании UTG Станислав Алексенко.

28.06.2023    5819    0    stnslv    5    

25

Технология проекта внедрения 1С:ERP – как управлять большим проектом

Управление проектом Команда Платформа 1С v8.3 1С:ERP Управление предприятием 2 1С:Управление холдингом Бесплатно (free)

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

10.02.2023    4654    0    andironenko    2    

31

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

Инструменты управления проектом Бесплатно (free)

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

27.12.2022    2733    0    MariaTemchina    28    

23

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

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

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

09.11.2022    4152    0    user1576201    10    

17

Я - ЗУПер! Часть 1. Компетенции сотрудников.

Бизнес-анализ Управление проектом Команда Управление ИТ Платформа 1С v8.3 Конфигурации 1cv8 Бесплатно (free)

Цикл статей о том, почему акушер-сантехник широкого профиля - это ПЛОХО. Расскажу плюсы специализации на одной предметной области. Рассмотрим понятные аналогии из других областей. Проанализируем пару вакансий, естественно без указания компании.

09.09.2022    10593    0    biimmap    79    

73

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

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

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

05.08.2022    13027    0    Evil Beaver    17    

116
Вознаграждение за ответ
Показать полностью
Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. MariaTemchina 1594 03.12.18 10:29 Сейчас в теме
Спасибо, прочитала с большим удовольствием!
Olga_aku; +1 Ответить
2. capitan 2461 03.12.18 11:18 Сейчас в теме
(1)Мария, спасибо за отзыв!
Для меня ваше мнение очень важно.
3. Timur.V 78 03.12.18 14:01 Сейчас в теме
"Чтобы корова давала больше молока и меньше ела - ее надо меньше кормить и больше доить."

Agile, Канбан - позволяют увеличить удои надои молока.
4. capitan 2461 03.12.18 14:09 Сейчас в теме
(3)
Agile, Канбан - позволяют увеличить удои надои молока

собственно чуть выше написано каким путем )
Они могут общую скорость разработки увеличить, но никак не количество написанного кода.
5. creatermc 27 03.12.18 14:15 Сейчас в теме
Достаточно на профессиональном уровне все описано, что бы ничего не пропустить надо будет подготовиться.
8. capitan 2461 03.12.18 15:20 Сейчас в теме
(5)Вот уже и Ричард Гир кодирует в 1С )
К чему подготовиться недопонял ?
6. acanta 03.12.18 14:34 Сейчас в теме
Гибкая разработка идеальна, когда у разработчика (программиста) есть чрезвычайно глубокое понимание предметной области. Проработал на родном предприятии на всех должностях, ушел(а) в декрет/ на повышение квалификации работать программистом, написал программу-скелетик, вернулся, внедрил по Agile c доработками по всем пожеланиям всех пользователей.И остался сидеть в уютном кабинете плевать в потолок и лайкать котиков отправился на вольные хлеба предлагать ее всем желающим, заодно привлекая народ в свое болото продвигая и осваивая эту сферу бизнеса с разных сторон.

ТЗ - это конспект для дипломной работы / краткое содержание Санта-барбары введение в предметную область, написанное языком понятным программистам/ методистам /заказчику хоть кому-нибудь из участников процесса.
Maks_Alexey13; A_Max; +2 Ответить
9. capitan 2461 03.12.18 15:23 Сейчас в теме
(6)Все точно. Хотелось бы только увидеть человека который поработав на всех должностях ушел работать программистом )
13. capitan 2461 03.12.18 16:09 Сейчас в теме
(9)ну дела. Здесь же был плюс) Куда смотрит модератор )
7. Valerych 03.12.18 14:39 Сейчас в теме
Каскадная модель (англ. waterfall model, иногда переводят как модель «Водопад»).
В качестве источника названия часто указывают статью, опубликованную У. У. Ройсом (W. W. Royce) в 1970 году; при том, что сам Ройс использовал итеративную модель разработки.
В 1970 году в своей статье Ройс описал в виде концепции то, что сейчас принято называть «каскадная модель», и обсуждал недостатки этой модели. Там же он показал как эта модель может быть доработана до итеративной модели.

Начиная с PMBOK 4-й версии удалось достичь компромисса между методологами, приверженными формальному и поступательному управлению проектом, с методологами, делающими ставку на гибкие итеративные методы. Таким образом, начиная с 2009 года, формально Институтом управления проектами (PMI) предлагается как стандарт гибридный вариант методологии управления проектами, сочетающий в себе как плюсы от методики «Водопада», так и достижения итеративных методологов.

Так получается, что внешне похожий на каскад, но только внешне, подход от PMI (можно PRINCE 2) и является той самой практикой, которую автор мог бы смело вписать в статью под. п.2 вместо более узкого понятия, которое критиковал даже "отец модели каскад/водопад" W. W. Royce.
10. capitan 2461 03.12.18 15:29 Сейчас в теме
(7)не совсем так.
Я как раз написал, что в 1С есть задачи классического водопада.
Пример - обновление форм отчетности,есть четкий срок, четкое понимание ресурсов и четкий прием задачи
Ничего итеративного здесь нет.
Если не накосячить конечно )
11. Valerych 03.12.18 15:45 Сейчас в теме
(10) Обновление форм отчетности это проект?

Выглядит как задача.
Конечно для задачи будут заданы сроки, выделены ресурсы и будет содержание/требования.

Пользуясь Вашей терминологией, так для задач не только ничего итеративного нет, но и ... ничего водопадного/каскадного нет.

Обновление форм отчетности нередко встречается как часть процесса сопровождения.
Попробовал визуализировать процесс состоящий из задач которые не задачи, а проекты, но очень маленькие ... казуистика ...
12. capitan 2461 03.12.18 15:56 Сейчас в теме
(11)
Обновление форм отчетности это проект
если базы 2 то задача, а если 222 то проект наверное
На мой взгляд отличие проекта от задачи и есть развернутое планирование трудозатрат и ресурсов, так то они очень похожи
14. Valerych 03.12.18 16:43 Сейчас в теме
(12) Есть такой сертифицированный PMI Иван Селиховкин, он дает интересную трактовку понятия проект.
https://www.youtube.com/watch?v=ZIAuc_P-rOw

Он подводит к неотъемлемым частям проекта конечность и высокую степень неопределенности.
Обновление форм отчетности не выглядит такой, что несет в себе неопределенность.

Получается, 222 базы требующие обновления форм отчетности, это не 1 проект, не 222 проекта, но это 222 задачи.
Задачи требуют планирования ресурсов, без этого они могут потеряться быть выполнены в самые неожиданные сроки.
15. capitan 2461 03.12.18 17:47 Сейчас в теме
(14)Посмотрю
А переезд офиса в новое здание - это проект?
23. GOshaSaveiko 38 05.12.18 09:59 Сейчас в теме
(15), я бы определил проект как временное мероприятие (имеющее дату начала, окончания) и совершенно определенную уникальную цель (не делалось ранее) и требующий организационных усилий. И так как переезд офиса в новое здание у вас не каждый день бывает, каждый раз разный, требует разного подхода и решений. То да, это проект.
Если бы вы занимались этим каждый день, например перевозили разные компании по одному и тому же чеклисту - это бы стало процессом.
16. capitan 2461 03.12.18 17:54 Сейчас в теме
(14)
высокую степень неопределенности
и вот это пока тоже не нравится
Совершенно не факт, что в проекте должно быть непонятно что, хоть бы он и по аджайл шел
Вспоминается ...
Купили как-то американцы у нас МИГ-29.Перед отправкой весь
его осмотрели-самолет как самолет,все на месте.Разобрали,перевезли
к себе.Собрали,смотрят-паровоз.Снова собрали-разобрали-опять паровоз!
В третий раз разобрали собрали-снова паровоз.Ничего понять не могут.
Вызывают одного из наших техников,спрашивают:"В чем дело?"А он им
отвечает:"Поставьте мне 3 ящика водки и зайдите через неделю..."
Приходят американцы через три недели,смотрят-стоит МиГ-29!Спрашивают
они нашего техника:"Как же ты его собрал?"А он им отвечает:"В инструкции,
внизу,мелкими буквами написано:"После сборки-обработать напильником!"
www.anekdot.ru ©
17. Valerych 03.12.18 18:28 Сейчас в теме
(16) Насчет неопределенности позвольте привести ссылку с рассуждениями Ивана Селиховкина.
https://infostart.ru/public/870848/
18. capitan 2461 03.12.18 19:31 Сейчас в теме
(17)Не очень с ними согласен. И понятие неопределенности тоже несколько загадочное.
Вот будете обновлять 2 базы и тоже есть неопределенность, может свет рубанут ?
Поэтому я бы представлял водопадный проект как то что можно нарисовать в Project - как классику: ресурсы, временная шкала, диаграмма Ганта )
А неопределенность оставим стадиону Зенит, как Иван справедливо отметил
20. Valerych 03.12.18 20:27 Сейчас в теме
(18)
Поэтому я бы представлял водопадный проект как то что можно нарисовать в Project - как классику: ресурсы, временная шкала, диаграмма Ганта )


Вы почти процитировали PMBOK.
Но современный PMBOK все же голосует за гибридные методы управления проектами (почти 10 лет уже как), т.е. водопад усиленный итеративными методами.

И да, п.2 как-то мощнее звучит, если заменить водопад на "методы классического проектного управления" :)
(в понимании PMBOK или PRINCE 2 на выбор)
21. capitan 2461 03.12.18 21:45 Сейчас в теме
19. capitan 2461 03.12.18 19:58 Сейчас в теме
(17)К тому же не забывайте - я говорю о проектах внутренних, там уставы не пишут
22. GOshaSaveiko 38 05.12.18 09:16 Сейчас в теме
У меня несколько иное мнение по поводу неопределенности и Scrum. Scrum хорош именно в условиях неопределенности. Когда четких требований нет, никто не знает как, но есть визионер, который примерно представляет куда надо идти. Скрам позволяет довольно быстро выкатить MVP и улучшать его короткими итерациями. Глупо писать подробное ТЗ, делать большой продукт, а в конце обнаружить, что 80% фич юзерам не надо. И вообще удобнее другой интерфейс и другая архитектура.
25. capitan 2461 12.12.18 16:48 Сейчас в теме
(22)Scrum хорош когда есть неопределенность и есть команда.
Это в 90% случаев не так
Нет команды - нет Scrum
24. FB_1811930315551820 05.12.18 10:30 Сейчас в теме
Прочитал обе статьи и комменты к ним с большим интересом. Потом сел с блокнотом и ручкой, немного подумал... еще раз перечитал обе статьи и отдельные комменты... и примерно понял, с чем не могу согласиться, как практик. Сейчас попробую связно изложить:
1. Автор все-таки недостаточно строг в использовании ключевых понятий. Проект - это не просто задача, алгоритм - это еще не метод, неопределенность не тождественна препятствиям в реализации, команда проекта - не просто совокупность всех вовлеченных в проект работников,ну и еще разное, по мелочам.
2. Если говорить о реализации именно проектов, именно методом роевого интеллекта - то или я так и не понял, в чем принципиальное ПОЛОЖИТЕЛЬНОЕ отличие роевого метода от методов Agile, или этого отличия просто нет. А есть только рекомендация НЕ использовать некоторые наиболее "пафосные" методы Agile - типа доски, стикеров, обязательных ежедневных митингов...
В конечном итоге, держа в уме, что: а) все мы по сути работаем по SCRUM/CanBan/Agile/e.t.c., только не знаем об этом, и б) суть любой стоящей теории может быть изложена так, чтобы ее понял младший школьник, хочу спросить у автора.
Все-таки, с точки зрения практики, в чем суть и новизна (а если усугубить - то и область наиболее эффективного применения) описанного им метода реализации проектов?
26. capitan 2461 12.12.18 17:00 Сейчас в теме
(24)Эта статья вообще классификация проектов и ни в ней ни в предыдущей нет рекомендации не использовать методы Agile и доски стикеры - как просто метод визуализации проекта к SCRUM/CanBan/Agile/e.t.c. имеющий посредственное отношение.

А вот
В конечном итоге, держа в уме, что: а) все мы по сути работаем по SCRUM/CanBan/Agile/e.t.c.
это как раз не так
И больше того скажу - тру программисты типа сеньоров не хотят так работать.
Потому что в существующей реальности - SCRUM/CanBan/Agile/e.t.c. - это просто старт работы без четкого понимания задачи и возможность поменять ТЗ в любой момент на диаметрально противоположное.
https://www.youtube.com/watch?v=UoKlKx-3FcA

А чистое гибкое программирование, как его понимали отцы основатели - это совсем другое
Оставьте свое сообщение