Эссе о прохождении курса обучения

Экологичный путь менеджера

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

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

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

Релиз-менеджемент

Вторую часть курса ведет Екатерина, исполнительный директор в «Сибирикс». Дается определение понятию и перечисляются существующие подходы. Ключевые моменты в каждом из них — тестирование и контроль качества. Первая часть — ручное тестирование. Рассматриваем на конкретных примерах — формах. На что опираться при тестировании: чек-листы, утвержденные результаты предыдущих этапов (ТЗ, прототип, бэклог), здравый смысл.

Этапность:

Тестирование дизайна. Объясняется суть метода «светофора» для проверки дизайна и не только.
Тестирование верстки. Популярный инструмент — плагин Pixel Perfect.
Валидность кода, загрузка на медленном канале, адаптивность.
Тестирование разработки.
Исследовательское тестирование.

Автоматизированное тестирование — это софт, тест скрипт (н: проверка заполнения формы), тест suit (комбинация тест скриптов, для проверки набора связанных функций). Инструменты — PHP unit, WebDriver/ Selenium. В конце части указываются + и — автотестетов. Вывод — автотесты нужно использовать по ситуации.

Виды тестирования: функциональное, не функциональное, связанное с изменениями.

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

Требовательность digital-продюсера

Требовательность — связна с властью и эксплуатацией. Рекомендована к прочтению книга Фридмана «Вы или Вас». Основная задача руководителя проектов — эффективная эксплуатация вверенных ресурсов. Существуют разные режимы, «нормальный»: грамотное планирование, настройка — постановка задач и целей, мониторинг и контроль, обратная связь, границы допустимого, системное обслуживание (отдых и обучение). «Форсированный»: допустим при наличии ясной цели и сроков окончания. Функции власти: планируй — делай — проверяй — воздействуй.

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

Генерализация частных случаев (увеличение задачи в объеме или сроках). Способы борьбы — тактика «варан-менеджмент», садишься рядом и сморишь как человек работает, возможно даже без понимания происходящего (недоступно для нас в настоящее время).

«Это невозможно». Способ борьбы — а) попросить переформулировать ответ, с указанием чего именно не хватает для выполнения б) напоминать об успешном выполнении в предыдущий раз.

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

Эффект генерации. В ответ на непонятные просьбы и указания задавать уточняющий вопрос «Что вы хотите чтобы я с этим сделал?».

Требовательность и мозгоклюйство. Мозгоклюйство — требовательность без предоставления необходимых конкретному исполнителю ресурсов (время, деньги, требования и пр.).

В конце модуля, как всегда, дается список литературы.

Аналитика в digital-проектах

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

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

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

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

Важно — при составлении персон моделируется не более 2-3 персон в рамках одного проекта, нужно выделить приоритетную персону, персонажи должны быть максимально реалистичными. Анализ сайтов конкурентов (реально существующих и проекты схожей тематики) — на предмет наличия хорошего и полезного (что можно перенять) и плохого (что, соответственно, перенимать не стоит).

Составление карты — с помощью средств *mind. Существует метод прогрессивного jpegа — проработка в зависимости от времени на проект, сначала — общая картина без детализации, далее — детализация каждого блока до нужной степени. Во время составления структуры выделяются этапы реализации (очередность согласно порядковому номеру) на карте. Прототип — интерактивная, как правило черно-белая схема будущего сайта. Основная цель — согласовать с заказчиком структуру сложных страниц и проверить удобство для конечных пользователей. Программы для прототипов - Axure, UXToolbox, Balsamiq, proto.io — для моб. приложений и пр.

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

Вторая часть модуля посвящена ТЗ. Главная проблема — возможные варианты двоякой трактовки написанного. Основная причина по которой клиент хочет ТЗ — привычка, подстраховка и аргумент в конфликтных ситуациях. Проще и легче тогда, когда ТЗ является дополнением к прототипу (поясняет то, что видно в прототипе с уточнением того, что нужно учесть). Состав ТЗ: общие сведения, цели создания сайта/ приложения, общие требования, настройка прав доступа, сео-требования, описание структуры страниц, структура базы данных, описание уведомлений. Приводится пример ТЗ рабочего проекта с разбором по пунктам (маркетинговое агентство).

Правильное делегирование в IT

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

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

Также существует боязнь идти на конфликт с подчиненными по разным причинам — испортить отношения, стремление избежать публичных ошибок, неуверенность давать распоряжения или неуверенность в подчиненных (не верное понимание, не хватает квалификации и пр). Требуемые качества руководителя: организованность, умение делегировать полномочия, понимание рабочих задач, умение делиться успехом, умение контролировать выполнение работ.

Уровни делегирования — уровень идеи (человеку с таким же уровнем ответственности и компетенции), уровень тезисов (такому же человеку, что и в предыдущем пункте, но уверенность чуть меньше), уровень задач (человеку с высоким уровнем квалификации, чье представление о результате соответствует моему), уровень упал — отжался (всем остальным — тикет-системы спасают от неправильной постановке в этом случае). SMART — конкретный, измеримый, достижимый, значимый и ограниченный во времени. Н: выкопать яму, 1*1* м, здесь, лопаты — там, можно для выполнения привлечь того-то и того-то, это нужно для посадки дерева, а так как уже начался сезон, яма нужна через 3 дня.

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

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

Негативная сторона — возможны проблемы при проверке и переводе задач в «готово». Вывод: постепенное ограничение одновременно выполняемой работы помогает выявить узкие места в организации.

Переговорные навыки

Продажи. Первая часть посвящена общим моментам и введению в продажи в it.

Вторая часть — пример как выглядит заказ услуг на стороне клиента. Процесс выглядит так: инициирование потребности со стороны руководителя в компании, делегирование обязанностей зачастую маркетологу (есть подобные примеры и у нас). Маркетолог (отдел маркетинга) может обратиться к собственным ресурсам компании (если они существуют), либо смотреть на рынок и выбирать подрядчика. Критерии выбора — цена и сроки, далее — качество обратной связи, минимальное количество вопросов со стороны подрядчика, наличие портфолио. Наличие ТЗ не гарантирует классный продукт в итоге.

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

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

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

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

Эскспресс-классификация клиентов. Нужна она в первую очередь для подстраивания под определенный тип клиента. Параметры: Открытый/ закрытый; Уверенный/ неуверенный

Дается краткая характеристика каждого типа. С примерами.

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

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

Конструктивный диалог. Управленческие поединки состоят из 3 частей: захват — прием — фиксация. По Тарасову все аргументы в диалоге расписаны по разным слоям (технический, правовой, экономический, эстетический и пр). Рассматривается построение подобной аргументации на примере конкретного кейса «подготовка к выставке».Внесение изменений в существующий сайт — правки по дизайну, новый функционал в личном кабинете, дедлайн 2 месяца. Реальность — по результатам может быть интересный кейс в портфолио, но работы минимум на пол года и требуется выход на руководство, чтобы убедить в своей точке зрения.Разыгрывается диалог между представителем компании разработчика и представителем компании-заказчика.

Оценка и декомпозиция проектов

Любая оценка должна начинаться с декомпозиции:

разбить на крупные блоки;
разбить блоки на страницы;
разбить страницы на составляющие.

«Откуда эта вещь на странице?» Возможные варианты: Это хардкод - от программистов и только они могут здесь что-то менять; Это включаемая область — наполнение правится из админки; Из базы; От стороннего ресурса — нужен протокол. API, ТЗ; Формула — откуда берутся коэффициенты?

Оптимальное, что можно сделать для выдачи оценки (сроков) — это настроить адекватную модель работы с неопределенностью.

Формула оценки: длительность работ = объем работ/ производительность.

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

Вероятность уложиться в интервал оценки 68% (по колоколу Гауса). Оптимально называть вилку сроков, указывая оптимистичную и пессимистичную оценку — так как она нужна для подстраховки.

Адекватная модель оценки. Если клиент очень категоричен предлагается убрать нижнюю границу, чтобы немного сгладить ситуацию. Часть рисков можно брать на себя (часть доработок/ правок, но не выходя в отрицательную прибыль). Аналитика оценивается отдельно. Нужно закладывать буферы и их контролировать и в нужные моменты проталкивать задачи. Для этих целей рекомендуют использовать Burndown Chart.

Оценки с опорой на прошлое и будущее. Принципы адекватной оценки: а) опираясь на свою картину в прошлом (свой наколенный опыт) и б) продлевая картину мира в будущее (экспертный опыт и интуиция). Чем больше опыт роботы и количество выполненных однотипных проектов (условно с одинаковой степенью сложности), тем соответственно и выше точность оценки сроков и понимание рисков.

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

Процесс оценки: постановка, анализ и предварительная оценка; ресреч; уточненная оценка, начало работы; выполнение задания; контрольная точка (и).

Подготовка вилочных и точных смет. Дается пример (таблица в Гугл докс) оценки min max этапов (аналитика, прототип, дизайн, верстка, разработка) для разработки интернет-магазина.

Откуда брать оценки (субъективные цифры от спикеров с учетом их тех процесса):

Аналитика — агрегация требований (средняя оценка 24 часа), прототип, (типовая 2-4, сложные — 8 часов, главная до 16 часов) техническое задание (8-24, до 40 часов сложные).
Разработка — определение типа проекта (корп, промо, им и пр), разбивка на крупные блоки (лк, каталог и пр), для каждого блока — иерархия типов страниц (вкладки, виды и пр).
Стоимость разработки = рейт* количество часов по задаче.
Дизайн — простые 2-4 часа, типовые 4-8 часов, сложные 8-16 часов, главная — отдельно, в зависимости от сложности.
Верстка — в среднем + 5-20% от дизайна, анимация всегда отдельно!
Тестирование — 20% от стоимости верстки и разработки.

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

Управление временем

Планирование по скраму: входящее (бэклог) — спринт — ретро (цикл). Методология GTD (getting thins done – доведение дел до завершения). Схема:

Рекомендуют evernote для планирования рабочего времени и дням недели и работы над задачами. Пропагандируется «принцип пустого инбокса».

Обзор системы OmniFocus. При планировании нужно оставлять «окна» на форс-мажоры, не менее 20%. Зачем планировать? Результативность, дороговизна ошибок, ограниченность ресурсов (время в частности), работа 24*7 приводит к выгоранию, планировать = управлять, принцип домино.

Метод набегающей волны:

Планируем детально ближайшую перспективу;
Планируем укрупненно отдаленные задачи;
Набегает волна — декомпозируем и детально планируем.

Пирамида Франклина:

План на день;
Краткосрочный план;
Долгосрочный план;
Генеральный план достижения цели;
Главные жизненные ценности.

Модель «Колесо баланса» в работе применима мало.

Планирование задач:

Сбор входящих в одном месте (эвернот, почта и пр);
Выберите время на сбор — 2 дня минимум;
Фиксация ВСЕХ задач, которые есть изо всех источников;
Не фильтруем задачи, только фиксация;
Перечитать все, что получилось — начинаем сначала.

Далее — формулировка (берем по одному пункту из входящих и облекаем их в задачи). Первое слово — объект с чем именно имеем дело, второе слово — действие с объектом. Н: полка: прибить. Важно — избежать плохих и непонятных формулировок без цели и артефакта! Далее — обработка по одной из схем. Можно использовать бумажный планинг (на любителя).

Матрица Эйзенхауэра. Две оси «важно» и «срочно», делит все поле на 4 квадранта в зависимости от важности и срочности соответственно.

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

Формирование плана на день:

Системообразующие задачи (5-7 шт в день);
Развивающие;
Дела, которые «хорошо бы сделать»;
Мелочи;
Утилизация (80%=6 часов), форс-мажоры (5%).

Концентрация — хорошо (техника Помодоро).

«График некидалова» — распределение проектов по дням недели. Н: такой-то проект только в пн, не отвечать и не заниматься другими проектами в этот день.

Работа с почтой — метод пустого inbox'а: разбираем 1-2 раза в день, максимально простая и удобная система хранения (архивирование), в конце дня — инбокс пустой.

Скрам

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

Agile-манифест:

Люди и взаимодействие важнее процессов и инструментов.
Работающий продукт важнее точной документации.
Сотрудничество с заказчиком важнее согласований условий контракта.
Готовность к изменениям важнее следованию первоначальному плану.

Фреймворк Скрама: Backlog (приоритеты — от бизнеса в первую очередь) – Sprint Backlog (та часть бэклога, которая принята в работу и оформлена в задачи) – Sprint (срок работы на выбранные задачи и предыдущего этапа + ретро после каждого спринта — разбор «полетов», оценка от команды «хорошо/ плохо») – Продукт (итерация/ версия).

Инструменты для ведения бэклогов. Представители рекомендуют таблицу в Гугл докс (спорное решение, там более сейчас). Колонки — приоритет, описание — безнесовые формулировки, est (оценка, первоначальные могут быть относительные). Имея оценки и приоритеты делим по релизам. Бэклог может быть более расширенным (подробное описание, указание раздела и пр.)

Следующий инструмент — trello (канбан-доска). Довольно удобный инструмент, но не для больших проектов. Scrumban – канбан-доска + файл эксель. Jira – одни плюсы).

Правила ведения бэклога:

Он должен быть, в одном экземпляре.
Приоритеты определяет product owner.
Чем важнее задача — тем выше приоритет.
Предварительные оценки в любых единицах - часах, в сторипойнтах.
Содержит бизнес-фичи, пользовательские истории, но технические задачи.

Роли в скраме: Product owner – связующий между командой разработки и заказчиком, знает цели. Команда разработки: Scrum master – член команды, отвечающий за выполнение процедур и за соблюдение интересов команды. Стейкхолдеры и пользователи.

Команда в скраме: 2-7 человек (+/- 1-2). Кроссфункциональность, совместное владение кодом, одной команды достаточно для реализации проекта полностью и, в идеале, она сидит в одном месте (в современном мире уже совсем необязательно)

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

Основное: cкрам — это фреймворк, его нужно настраивать под себя. Это не отменяет необходимость думать, инструментом нужно пользоваться с умом.

Минимальная отчетность и проведение стендапов.

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

На стендапе поднимается 3 основных вопроса: Что было сделано вчера? Что будет сделано сегодня? Какие есть проблемы? Во время проведения следует соблюдать простые правила — не разговаривать по телефону, не раздражать присутствующих, не опаздывать, не разводить дискуссию.

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

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

Пример аномального поведения:

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

Фокус фактор — коэфф., который показывает концентрацию команды над проектом (для новых команд 70%).

Производительность (Velocity) = Focus Factor * оценка новых задач.

Work ni progress — все незавершенные задачи на текущий момент.

Диаграмма производительности:

Для адекватной оценки нужно чтобы длительность спринта и число человек в команде не менялось (и состав).

Контроль качества. Тестирование лучше проводить на ранних этапах + желательно иметь встроенные механизмы автотестирования. 2 варианта — закладывать время на конец спринта для баг фикса или ежедневное тестирование.

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

Рекомендации по проведению от Сибирикс:

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

Культ «карго» в IT: ни один инструмент не заменяет голову; инструментами нужно работать.

Смотрим на результат, анализируем.

Решение факапов

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

Решение было предложено компанией Тойота, и именно Таичи Оно. Стратегия — сократить время от получения заказа до сдачи продукции и получения оплаты. Было предложено выстроить непрерывный поток единичных изделий.

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

Виды возможных потерь:

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

Well you stream map. Изучить рабочий процесс, устранить потери — убрать те операции, которые не несут ценности.

5 Why. При возникновении проблемы нужно искать ее причину и задавать последовательно вопросы «почему». На каждом из 5 уровней ищем «противоядие».

5С — сортируй, содержи в чистоте, совершенствуй, стандартизируй, соблюдай порядок.

ТОС — теория ограничений. Предполагается, что нужно найти слабое звено и подчинить ему весь поток.

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

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

Диаграмма Исикавы:

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

Дерево текущей реальности:

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

Root cause анализ:

После выяснения причин проблемы нужно предложить «инъекции» — способы устранения проблем (желательно несколько вариантов для выбора). Для каждого из вариантов устранения нужен план с ожидаемым результатом.

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