Владимир Завертайлов

8 сортов муды в твоей веб-студии

Эта короткая заметка для тех, кто системно ищет, где его студия теряет деньги. Похвальное занятие в наше весёлое время.

Муда, что по-японски означает «потери» — это любая деятельность, которая потребляет ресурсы, но не создает ценности для клиента. (Источник).

Хорошо систематизировали виды потерь ребята из Toyota. Тойотовцы выделяют 7-8 видов муды, потерь на производстве. Посмотрим, есть ли аналоги между потерями в автомобилестроении и работе студии.

Муда № 1. Потери из-за лишних запасов

В студии: Вся незавершенная или несданная работа.

  • Несданный дизайн.
  • Недоверстанный макет.
  • Непротестированный код.
  • Незапрограммированные требования.
  • Незадеплоенный код.

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

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

Что делать: Всеми правдами и неправдами старайтесь сократить количество несданной, одновременно выполняемой работы. Лучше довести один проект до конца и затем приступить к следующему, чем взяться за 4-5 и делать их параллельно.

Муда № 2. Потери при ненужной транспортировке

В студии: Повторное обсуждение одного и того же вопроса, по которому уже принято решение (Relearning).

Например, вы пришли к выводу, что не плохо бы использовать в студии какую-то систему контроля версий. Тщательно изучили вопрос. Собрались, обсудили плюсы и минусы. Похоливарили, что лучше — GIT или SVN. Реально полностью разобрались в вопросе. И как стандарт у себя решили принять svn. Внедрили как стандарт. Обучились. Начали использовать.

И вот через полгода какой-то умник говорит: «Ребята! А почему мы используем SVN, а не GIT? SVN же говно, потому, что <аргумент>, а GIT — это круто потому, что <еще какой-то аргумент>». На самом деле через полгода никто уже не помнит, то ли эти аргументы уже рассматривались (и вы вместе пришли к выводу об их недостаточности), то ли эти аргументы вы пропустили при обсуждении. Приходится изучать вопрос повторно. Тратить время, вместо того, чтобы делать деньги.

Что делать: Фиксировать не только решения, но и контекст и аргументацию по принятым решениям. Здесь хорошо работают диаграммы (Root Cause-анализ, Mind Map, A3-анализ). Найти баланс между пересмотром своих процессов/средств разработки и соблюдением принятых стандартов.

Муда № 3. Потери из-за перепроизводства

В студии: Ненужная функциональность.

Так прикольно бывает запилить для клиента пару фишечек, пасхалочек или полировать фотографии на какой-то странице 5-го уровня, на которую никто никогда не зайдет или оптимизировать страницу «Наше руководство» для скорости загрузки в 0.005 сек.

Общая идея: делать функции, которыми никто не будет пользоваться (и на которых ваш клиент не заработает) — это потери. Пример-лидер — это MS Excel: 95% пользователей постоянно используют только 5% функций. Нафига всё остальное?

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

Муда № 4. Потери времени из-за ожидания

В студии: Затягивание согласований.

  • Ожидание согласования с заказчиком;
  • Внутренние согласования;
  • Бесполезные совещания, обсуждения и личные встречи;

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

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

Что делать: сократить количество вовлеченных в проект людей до минимума. Принимать решения максимально оперативно. Сократить количество совещаний и личных встреч. Если уж и проводить собрание — иметь четкий регламент, фиксировать и четко соблюдать договорённости.

Муда № 5. Потери из-за выпуска дефектной продукции

В студии: Баги.

Что важно знать про баги: чем позже дефект найден, тем он дороже. Если вы, допустим, программист, и находите и фиксите баг сами и сразу — это стоит дешево. А вот если его находит клиент — то это уже чревато. Особенно, когда баг найден через два года, уничтожил базу данных клиента, а программист, который писал код — в отпуске, в другом городе и умер.

Что делать: как можно более раннее тестирование. На крупных проектах — автоматические тесты. Четкие стандарты кодирования. Регулярные практики code review. Наставники для новичков.

Муда № 6. Потери из-за ненужных перемещений

В студии: Потери передачи проекта.

Потеря передачи:

  • Ответственности.
  • Знаний.
  • Проектов.
  • Действий.
  • Заявок.

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

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

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

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

Муда № 7. Потери из-за лишних этапов обработки

В студии: переключение разработчиков между большим количеством разных задач

Человеческий мозг плохо приспособлен к многозадачности. Пока мы переключаемся с проекта на проект — мы теряем контекст задачи. На восстановление контекста нужно от 15 минут до получаса. Это чистые потери. Считайте, если вы дернули человека — это вы слили 15 минут. Помножьте на ваш рейт, вычтите у себя из зарплаты. Если будет жадно — не дергайте. Если не жалко и вопрос того стоит — можно дернуть.

Кстати, если ваш программист способен переключать контекст быстро — это значит, что в нем сильны задатки менеджера.

Что делать: не дергайте людей

Муда № 8. Нереализованный творческий потенциал сотрудников

В студии: Долбаная рутина.

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

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

Что почитать


 

Что еще почитать по этой теме

Условия хранения коммерческой тайны
Сибирикс
26 Апреля 2016
Условия хранения коммерческой тайны
Как не наболтать на пару миллионов штрафа? Грамотно составлять и внимательно читать NDA. Или брать наш вариант — он ждёт вас внутри.
Опасности SEO-продвижения: как выйти в топ и не сломать сайт
Сибирикс
13 Апреля 2016
Опасности SEO-продвижения: как выйти в топ и не сломать сайт
Продвижение и оптимизация сайта — не так просто, как могут уверять SEO-компании. Мы решили морально подготовить вас ко всем форс-мажорам
Иллюзия безопасности вашего интернет-проекта, господин клиент!
Владимир Завертайлов
16 Марта 2016
Иллюзия безопасности вашего интернет-проекта, господин клиент!
О том, что все и так прекрасно понимают, но, как известно, пока гром не грянет...

У вас есть проект?

Давайте обсудим его. Продумаем. И сделаем!

Заказать клёвый проект
Заявка отправлена
Спасибо, ваша заявка отправлена. Эксперт студии Сибирикс свяжется с вами в ближайшее время для уточнения подробностей.