PMI, Scrum и Kanban – как работать с содержанием (scope) в каждом из подходов и где границы его применимости

Публикация № 1663869 23.05.22

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

PMI Scrum Kanban

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

Меня зовут Иван Селиховкин, я руководитель проектов в 15-летним стажем.

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

Но в прошлом я как руководитель проектов довольно долго с этим работал и хорошо понимаю, какие подходы – гибкие или классические – лучше применять в тех или иных случаях.

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

Давайте я сначала представлюсь, а потом вернусь и объясню, о чем пойдет речь.

  • У меня очень разнообразный опыт проектной деятельности – в основном, в сфере ИТ и производства. Например, мое предыдущее место работы – компания, производящая медтехнику. Мы создавали аппаратуру и разрабатывали для нее софт. При этом львиная доля моих проектов – это ИТ-проекты. Сюда относится самая разная разработка – заказная, продуктовая и т.д.

  • Я работал в больших и маленьких компаниях, в бюрократичных и не очень. Когда-то давно работал в госсекторе, теперь, к счастью, там не работаю. Я это говорю к тому, что на своем опыте знаю, как работает проектное управление в самых разных видах.

  • На тему управления проектами я часто выступаю и периодически подтверждаю свои знания – сдаю экзамены и получаю сертификаты.

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

 

Основные управленческие подходы: как выбрать подходящий

 

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

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

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

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

 

 

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

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

Предлагаю вам вместе со мной в течение 20 минут пробежаться по методам и погрузиться в них.

  • Во-первых, я покажу, что означает выбор подхода в контексте работы с содержанием.

  • Во-вторых, расскажу, где границы применимости подходов – как вы сможете работать с содержанием, применяя Скрам, а как – маловероятно, не ломая сам Скрам.

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

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

 

На что ориентируется менеджер, думая, выбрать ему Скрам, PMI или Канбан?

  • Первое – это его субъективное впечатление, что он больше любит, о чем он чаще слышал на конференциях.

  • Второе – он смотрит на всякие вспомогательные вещи вроде Cynefin-framework (произносится как Кеневин-фреймворк).

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

  • Если система сложная (внутри системы много связей), то, скорее, нужен классический подход в управлении проектами.

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

Специфика Кеневин-фреймворка в том, что он подталкивает большинство людей найти свой проект в верхнем правом квадранте. Большинство людей, которым объясняешь, как работает Кеневин-фреймворк, говорят: «Да, у нас запутанная система – у нас и заинтересованных сторон много, и изменчивость высокая, и требования меняются».

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

А теперь давайте посмотрим на это в разрезе работы с содержанием.

 

Реалии работы с заказчиком

 

Что такое работа ИТ-менеджера, ИТ-команды? Как ни крути, ИТ-команда – это люди, которые оказывают некоторые услуги заказчику. Это очень общее утверждение, но это примерно всегда так. Есть некий заказчик, который обычно очень смутно понимает, чего хочет. У него есть какое-то представление о своей идее, но он не может объяснить деталей до конца. С этим он приходит к ИТ-команде.

Почему это почти всегда так? Потому что в жизни работает эмпирическое правило: если человек до деталей знает, чего он хочет, он, как правило, сам это может сделать.

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

Так вот заказчик – это почти всегда человек, который не знает деталей, потому что, если бы он их знал, он бы к вам не пришел. Он примерно понимает, чего хочет, и приходит к ИТ-команде за какой-то услугой.

 

Какие варианты есть у ИТ-команды в таких условиях:

  • Первое – до деталей или хотя бы до среднего размера блоков прояснить, чего заказчик хочет, зафиксировать все это, и пойти работать. Это – один подход.

  • Другой подход – не париться и делать, что сказали. Например, у заказчика внедрена какая-то бухгалтерская ИТ-система, и он хочет ее доработать – что-то выгрузить, поменять, сделать новый отчет. От него прилетают задачки, и он сам говорит, что приоритетней. А что приоритетнее, то мы и берем в работу первым.

  • Третий вариант – мыслить какими-то блоками, которые имеют для заказчика значение. Это еще можно назвать термином MVP (minimum viable product). Заказчик накидал каких-то идей – например, он хочет мобильную игру, в которой будет 80 уровней, 50 персонажей, возможность покупать, продавать оружие и так далее. Мы ему говорим: «Хорошо, давайте из этого сделаем версию 1.0». Решаем, что в нее должно войти минимально, чтобы в это уже можно было играть, а остальное мы будем наращивать постепенно. Мы этот MVP формулируем, и дальше его реализуем.

На самом деле большинство современных менеджерских ИТ-подходов находятся где-то в этой системе координат.

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

  • В правой части – подход, в котором можно распознать Скрам. То, что нарисовано, очень напоминает Scrum backlog. Но при этом точно так же можно использовать и Канбан-метод, и классический подход.

  • Посерединке – подход типа: «Вы скажете – мы сделаем». С таким подходом вполне совместим Канбан-метод, а остальные подходы (Scrum и PMI) не очень хорошо так работают.

Таким образом, если перед нашим менеджером стоит заказчик, который смутно представляет, что хочет, можно:

  • либо начать все прояснять до деталей;

  • либо слушать заказчика и брать в работу то, что он скажет;

  • либо третий вариант – нащупать какой-то MVP, сделать его, потом еще раз подумать, отобрать новый кусочек функциональности, его сделать, и такими кусками дальше «есть слона».

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

 

Главное ограничение в применении Скрам – MVP

 

Начнем с MVP, попробуем сформулировать из задач заказчика продукт, который имеет какую-то минимальную полезную ценность.

Тут очень важно понимать, что Scrum-framework целиком стоит на парадигме MVP. Он говорит, что работу нужно разбить на двухнедельные тайм-боксы (спринты) и работать вот такими спринтами. Спринты могут быть и трехнедельными, но не больше месяца и уж точно не меньше недели.

Смысл Scrum-framework в том, что после одного-двух-трех спринтов вы должны быть в состоянии выдать MVP.

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

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

Гораздо полезнее было бы, если бы мы посадили врача, и он сам попробовал бы разобраться в этой системе. Ценность сразу кратно больше. Это суперценность, которую Scrum пытается извлекать. Он говорит: отдайте продукт человеку в работу, посмотрите, как он мучается, сделайте выводы и доработайте.

 

В чем ограничения в применении Скрам?

Очень многие люди неправильно понимают, что такое MVP. К сожалению, очень много в интернете дурацких картинок, которые сбивают с толку. На слайде приведена неплохая картинка на эту тему.

  • Наверху показан путь создания продукта не через MVP. Клиент захотел машину – мы ему сначала сделали колесо, потом шасси, потом кузов и только потом машину. Пока мы не достигли последней стадии, клиент ничем пользоваться не мог.

  • Во второй строке тоже не MVP. Да, клиент хотел машину. Зачем мы ему пихаем велосипед, потом самокат, потом мотоцикл? Есть известный тезис, что нельзя построить мост по Скраму. Да, нельзя – я об этом много раз говорил и еще раз повторю. Как бы прекрасно люди вроде Сазерленда не писали о том, что они делают ремонт по Скраму (когда делается одна комната, они живут в другой), в общем случае и к строительству, и к производству Скрам плохо применим.

  • Для понятия MVP реально подходит только нижняя строчка. Обращайте на это внимание.

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

Я говорил: «Стоять! Какой у нас MVP?» – они говорят: «у нас MVP – сервер» – «Отлично, значит, MVP у нас в конце. Можем ли мы посередине проекта, в первую треть проекта дать заказчику в руки что-то полезное?» – «Нет не можем».

Посередине проекта у нас будет структура баз данных сервера, у нас будет железка с припаянными платами – аппаратный комплекс, которым нельзя пользоваться без софта. Мы можем это показать, как промежуточный результат, но обратную связь собрать мы не можем. Если мы не можем этого сделать, значит, сюда не нужно тянуть продуктовые подходы типа Скрама. Потому что мы не в состоянии часто выдавать заказчику отчуждаемый результат, с которым он будет жить. Это очень важно оценивать заранее.

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

В качестве возражения на этот пример обычно говорят: «Пока строится мост, можно дать заказчику паромную переправу или объездную дорогу, и пусть он пока этим пользуется». Хорошо, представьте заказчик ездит по вашей паромной переправе или объездной дороге. Какую обратную связь вы от него получаете? Нравится ли ему ваш мост? В том-то и дело, что здесь, как на второй строчке слайда, вы дали ему совершенно другой продукт и собираете совершенно ненужную обратную связь. Он и без вас, наверное, умел ездить на другую сторону – ему мост нужен.

 

Скрам и Канбан не применимы при большом количестве взаимосвязей

 

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

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

Второе ограничение при выборе гибких подходов – это взаимосвязи. Это ограничение касается:

  • и подхода Канбан «Что сказали, то и делаем», где на доске у нас задачи из колонки ToDo едут вправо в сторону Done;

  • и подхода Скрам «Попробуем сформировать MVP и cделать его», где бэклог продукта реализуется через спринты и бэклоги спринтов.

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

Покажу на примере.

 

 

На картинке – пример Канбан-доски с задачами и ответственными.

Обратите внимание, что в Канбане есть две необязательные роли:

  • Service Request Manager – тот, кто пополняет и приоритизирует колонку ToDo, он здесь в красной шляпе;

  • Service Delivery Manager или Flow-мастер – следит за потоком и ограничивает незавершенную работу, он здесь показан в серой шляпе

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

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

 

 

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

Такие блокеры есть возможность установить и в Jira, и в Kaiten. А в классическом Канбане все блокеры и взаимосвязи между ними держит в голове Service Delivery Manager (дядька в серой шляпе).

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

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

Когда все залеплено блокерами, Канбан-метод плохо работает. У вас ломаются метрики – вы не понимаете, почему ползут вверх Cycle Time, Time-to-market и прочее. Но мы сейчас не про время, мы про содержание.

Так что же с этим делать? А ничего.

У Канбан-метода посыл такой же, как у Scrum framework – он звучит примерно так: «Минимизируйте зависимости в бэклоге, формулируйте задачи так, чтобы между ними не было зависимостей, или их было меньше». Если между собой связаны две-три задачи – это не проблема, но, когда каждая вторая задача связана с еще двумя – это офигенная проблема. Фактически ваш бэклог превращается в диаграмму Ганта, но поскольку в Канбан-методе это не очень уместно, то зависимости вы заменяете на блокеры.

Это еще одна граница применимости. Если вы обратитесь к известному Канбан-тренеру и спросите у него, что делать с большим количеством зависимостей, он, скорее всего, ответит вопросом: «Уверены ли вы, что у вас уместен Канбан-метод?». Мне несколько очень знаменитых Канбан-тренеров уже так отвечали.

Повторю: блокеры и зависимости – это ограничения в применении Канбан-метода и Scrum. Можно применять, но чем больше будет зависимостей, тем больше вы будете мучиться.

Источники дополнительных взаимосвязей при использовании Канбан-метода

 

 

Кроме этого, при приемке задачи и проверке критериев готовности – Definition of done (критерий полной готовности задачи) и Acceptance criteria (критерий того, что задача не просто готова, а еще и работает так, как надо заказчику) также могут возникать зависимости в виде ряда дополнительных задач, среди которых какие-то – очевидные, а какие-то – нет. Тут тоже нужно быть внимательным.

И еще одно, последнее. Возможно, это прозвучит неочевидно, но среди каденций – регулярных мероприятий, которые вы проводите при использовании Канбан-метода, есть такая вещь, как Delivery planning meeting – собрание планирования поставки.

Все каденции, используемые в Канбан-методе, показаны на слайде.

 

 

Delivery planning meeting проводится по мере выпуска релизов – на этой встрече вы обсуждаете, о чем нужно не забыть подумать при ближайшей поставке, что в эту поставку включить. Такие встречи проводятся, помимо прочего, еще и для того, чтобы подумать, что дополнительно не-ИТ-шного нужно не забыть сделать.

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

Delivery planning meeting – это еще один источник зависимостей, поэтому, возможно, его имеет смысл запустить по доске отдельной карточкой, чтобы про эти зависимые задачи не забыть.

Повторюсь: когда зависимостей становится много, Канбан-метод начинает буксовать.

 

Влияние взаимосвязей на Скрам

 

 

Со Скрамом та же самая история. На слайде показано, как устроен Скрам – бэклог, спринты, красота.

Причем в бэклоге Скрама лежат не только User Story, но и всякие прекрасные вещи вроде технического долга, RnD-задач и всякого такого.

И тут возникает та же самая проблема: если в бэклоге много взаимосвязей, работать по Скраму сложно.

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

Поэтому просто найдите человека, который будет уметь при помощи всяких Story Map, Customer Journey Map и прочего придумывать, что нужно делать в первую очередь, а, во-вторых, держать в голове взаимосвязи, которые плодятся в бэклоге.

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

Пока этих взаимосвязей немного – все прекрасно.

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

Ограничения применимости классических подходов

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

В отличие от тех подходов, о которых мы говорили раньше, он предполагает, что:

  • мы собрали требования, структурировали их;

  • потратили время на то, чтобы из требований бэклога сделать целостное ТЗ;

  • потом вы это ТЗ превращаете в некую иерархическую структуру работ;

  • а на основе иерархической структуры работ вы строите сетевую диаграмму – то, что менеджмент называет диаграммой Ганта.

Плюс диаграммы Ганта в том, что она узаконивает зависимости.

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

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

 

 

Почему же тогда считается, что работать с требованиями по классическим подходам сложно?

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

  • Кроме этого, у классических подходов гораздо более высокая стоимость –первоначальная проработка занимает много времени, а у бизнеса столько времени очень часто нет, он не готов столько ждать, он говорит: «Поехали, потом заведешь!» Кроме этого, нужно еще поддерживать целостность всего этого. А что делать, если заказчик решил внести правки в ТЗ, пришел с новыми требованиями? Они должны пойти по цепочке – мы должны скорректировать ТЗ, скорректировать диаграмму Ганта. И это гораздо сложнее, чем докинуть User Story в бэклог, и ее там приоритизировать. И гораздо дороже во времени. Правда, когда у вас достаточно сложная система, у вас может не быть другого выхода, и вам придется потратить это время, но в целом – цена такая.

  • Еще одна проблема классического подхода – это проблема экспертности. Чтобы написать ТЗ и сделать иерархическую структуру работ, у команды должно быть большое количество экспертных знаний. В команде должны быть аналитики, люди, которые умеют работать с требованиями. В Скраме или в Канбан-методе иметь аналитиков в команде не обязательно, потому что в Скраме есть бэклог, который мы потихонечку прорабатываем и уточняем. А в классическом методе у вас должна быть высокая планка экспертных знаний. Это – еще одно важное ограничение.

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

 

Выводы

 

Обобщаем все, что я сказал.

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

В такой ситуации у нас есть три варианта, как двигаться дальше:

  • либо прояснять до крупных блоков,

  • либо вообще не париться, брать задачки, которые он приносит,

  • либо мыслить категориями MVP.

У каждого из этих вариантов есть свои проблемы – они все сейчас на слайде:

  • для Scrum обязателен MVP – но быстродоступный MVP есть не везде;

  • для подходов Scrum и Kanban – есть проблема взаимосвязей (возникают блокеры);

  • проблема взаимосвязей лечится классическим подходом, но там своя цена – это дорого, трудоемко и требует экспертных знаний.

 

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

Cynefin-фреймворк для запутанных систем подталкивал нашего менеджера к выбору Agile-подходов. А мы сейчас рассмотрели еще один аспект выбора – с точки зрения работы с содержанием. Я вам попытался рассказать показания и противопоказания к выбору того или иного подхода в зависимости от содержания требований в проекте.

 

 

Еще раз напомню подходы, про которые мы сегодня говорили:

Если что-то из этого вы не читали, можно посмотреть.

 

Вопросы:

 

Если невозможен MVP, невозможны небольшие релизы, может ли быть польза от применения Скрам?

Я верю, что нет, потому что, если релизы бесполезны, то бесполезен и Скрам. Мы в Скраме очень многим жертвуем, например, нормальной оценкой сроков (мы ее считаем через стори поинты). И всё ради того, чтобы получать петлю обратной связи от заказчика быстро и максимально практично. А если этого не происходит, то это спринт ради спринта. Еще раз, нарезать на кусочки можем что угодно.

Может быть, Скрам на стройке начинается с уровня мастера участка?

Насчет мастера участка спасибо, это интересная аналогия. Но если начальнику участка нужно спроектировать и построить ангар – какой тут может быть MVP?

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

Может быть Петрович умудрится выдать полезный результат какому-то своему внутреннему владельцу продукта, но на уровне стройки в целом, для заказчика, который ждет дом, дом по Скраму не построишь.

Но когда мы дробим стройку на команды, эти команды внутри могут работать по Скрам. Вот у нас так в проектном офисе тоже есть. Сверху Канбан, а снизу – Скрам-команда, например.

Терминологический вопрос – вы сначала обозначили подходы как Скрам, Канбан и PMI. Как вы считаете, правомерно ли название подхода PMI, если со 2 января 2021 года в требованиях к основному экзамену PMP половина вопросов уже касается гибких методик управления?

Я могу называть подход PMI длинно – «классический подход к управлению проектами, такой как PMI, Prince 2 и т.д». А могу кратко – PMI-подход.

Я просто постарался донести мысль, что, когда я говорю PMI, я имею в виду подход, основанный на сборе требований, формализации их в ТЗ, и превращение их в диаграмму Ганта.

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

То же самое – Prince сейчас поделился на Prince классический и Prince for Agile. Классический подход никуда не делся, он существует для проектов, у которых много внутренних связей, блокеров и всего остального.

От того, что, что PMBoK 7 изменится, а PMBoK 6 стал включать в себя приложение по Agile, не значит, что исчез классический подход. Он никуда не исчез, его просто нужно каким-то словом назвать. Модель Cynefin никуда от нас не делась – все остается.

 

*************

Данная статья написана по итогам доклада (видео), прочитанного на онлайн-митапе "Сбор требований и составление ТЗ: современные подходы в управлении проектами". Больше статей можно прочитать здесь.

Приглашаем всех 6-8 октября принять участие в INFOSTART EVENT 2022 в Санкт-Петербурге: //infostart.ru/events/1573038/

*************

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

Оставьте свое сообщение

См. также

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

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

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

16.09.2019    14097    GSoft    21    

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

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

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

05.08.2022    6561    Evil Beaver    14    

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

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

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

11.05.2022    4056    1c-intelligence    47    

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

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

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

02.02.2022    4034    denisgalimoff    3    

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

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

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

24.01.2019    11199    user809424    11    

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

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

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

07.09.2021    7181    MariaTemchina    0    

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

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

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

30.07.2021    7639    MariaTemchina    12    

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

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

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

14.05.2021    4176    G.Shatrov    6    

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

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

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

09.06.2017    33572    1СERP    175    

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

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

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

12.03.2021    7372    MariaTemchina    86    

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

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

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

16.02.2021    4050    MariaTemchina    45    

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

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

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

12.02.2021    4103    MariaTemchina    17    

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

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

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

18.04.2017    34993    1СERP    189    

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

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

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

10.02.2021    5641    andironenko    15    

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

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

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

09.12.2020    2654    MariaTemchina    3    

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

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

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

03.12.2020    5653    MariaTemchina    9    

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

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

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

10.04.2017    35081    1СERP    107    

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

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

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

18.11.2020    6318    MariaTemchina    9    

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

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

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

05.10.2020    3886    primat    2    

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

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

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

18.09.2020    5080    IvanAT1981    5    

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

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

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

03.04.2017    46550    1СERP    233    

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

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

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

15.09.2020    3012    MariaTemchina    5    

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

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

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

11.09.2020    4120    alexandr.blinov    17    

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

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

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

07.09.2020    2908    RKurbanov    3    

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

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

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

17.06.2016    41987    raiml    37    

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

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

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

04.09.2020    4616    MariaTemchina    30    

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

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

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

24.07.2020    3062    Soliton    10    

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

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

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

21.07.2020    3988    MariaTemchina    1    

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

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

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

26.12.2014    47106    CheBurator    66    

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

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

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

26.06.2020    5498    1c-intelligence    17    

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

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

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

13.06.2020    3414    Koder_Line    9    

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

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

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

08.06.2020    7621    MariaTemchina    0    

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

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

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

1 стартмани

14.09.2015    37412    axxell    15    

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

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

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

01.06.2020    8932    MariaTemchina    4    

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

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

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

25.05.2020    6781    sapervodichka    1    

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

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

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

18.05.2020    13244    MariaTemchina    33    

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

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

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

13.11.2014    28702    raiml    236    

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

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

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

23.03.2020    7866    MariaTemchina    26    

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

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

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

21.03.2020    4778    oleynik.dv    7    

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

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

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

10.03.2020    5404    VLikhobabin    6    

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

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

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

13.05.2014    140415    Evgen.Ponomarenko    5    

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

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

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

03.03.2020    9558    VLikhobabin    44    

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

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

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

23.01.2020    42051    MariaTemchina    12    

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

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

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

27.10.2013    54290    nurpoz    157    

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

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

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

04.01.2020    6744    capitan    52    

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

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

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

26.12.2019    12486    Mistress_A    28    

Про одну Тётю

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

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

24.12.2019    7545    1c-intelligence    33    

Схема повышения качества работы с клиентами Промо

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

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

17.10.2013    39845    nurpoz    41    

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

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

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

14.10.2019    6524    chavalah    16    

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

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

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

19.09.2019    14553    ogroup    165    

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

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

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

20.08.2019    11097    Arsen1986    7