40 проектов в месяц. Как увеличить производство и не затрещать по швам?

В статье «12 тыс. рублей за сайт. Есть ли бизнес за МКАДом?» я писал про наш подход к разработке сайтов на базе созданной внутри компании технологии. На момент написания мы выпускали «под ключ» 24 сайта в месяц. Это больше чем один сайт в день силами команды из 8 человек.

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

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

Осознание проблемы

Первое, что нам пришлось сделать, - это временно увеличить обещанный срок разработки с 5 до 8 (а иногда и 10) дней. У нас просто не было выхода. Клиенты отнеслись с пониманием и были готовы ждать. Но мы не были готовы ждать, пока ситуация станет еще более сложной. Нужно было что-то предпринимать. По всем показателям (и нормативам) команда должна была справляться, но этого не происходило.

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

Процесс непрерывного улучшения

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

Rabota-v-komande.jpg

Одно звено принимает заявки, другое принимает проект в работу, далее следуют дизайн, сборка, доработка и прочие этапы. Если хотя бы одно звено дает сбой, то весь процесс замедляется или вовсе останавливается. И тут есть важный вопрос: что определяет прочность цепи? Естественно, самое слабое звено. Надо заметить, что самое слабое звено в любой цепи всегда одно, и это ключевой момент подхода к управлению производством. Этот подход в промышленном мире описан «теорией ограничений» («The Theory of Contains»).

Остановимся на ней подробнее. Допустим, в цепи производства ваша роль – сборка сайта из готового дизайна. Вы не самое слабое звено. В результате собственной гениальности и трудоспособности вы начали выполнять свою работу в два раза быстрее. Насколько вы увеличили производительность всей цепи? Абсолютно ни на сколько. Большинство локальных улучшений не влияет на производительность всей команды. Это значит, что принцип «чем больше, тем лучше» не является тем путем, который приведет к повышению общей эффективности цепи.

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

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

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

Синхронизируем скорость работы, балансируем производство

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

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

rost-srokov.jpg

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

Распараллеливание проектов уменьшает скорость всей цепи и повышает затраты

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

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

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

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

5 проектов на менеджера

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

proekty-na-menedjera.jpg

5 дней на проект

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

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

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

Все остальные причины малозначительны по сравнению с первыми двумя.

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

Так выглядит цепочка создания сайта сейчас:

optimizacia-raboty.jpg

Это пока промежуточные решения. Они еще не прошли должного испытания временем. Но по большей части проектов мы вернули клиентам обещанные пять дней и восстановили спокойствие в команде. К настоящему моменту производительность центрального офиса выросла до 36 проектов в месяц (по итогам мая 2012 года).

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

Резюме

Кратко резюмируем подход по непрерывному улучшению потокового производства.

Первый шаг — найти ограничение системы. Что в настоящий момент задает ее максимальную производительность?

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

Шаг третий — подчинить скорость всего производства скорости работы узкого звена.

Четвертый шаг — расширить узкое звено.

Шаг пятый — вернуться к первому шагу, но помнить об инерции

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

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

P.S. Были просьбы написать о «смертности» недорогих проектов, их реальной пользе для клиентов и пр. Пока собираем отзывы и статистику. Скоро будет небольшой анализ.

Расскажите коллегам:
Эта публикация была размещена на предыдущей версии сайта и перенесена на нынешнюю версию. После переноса некоторые элементы публикации могут отражаться некорректно. Если вы заметили погрешности верстки, сообщите, пожалуйста, по адресу correct@e-xecutive.ru
Комментарии
Технический директор, Москва

Красивая авторская иллюстрация TOC. Правда, при такой скорострельности проектный подход не эффективен. Может имеет смысл задуматься о других методах? Навскидку, у вас в компании чистый конвеер.

Консультант, Ростов-на-Дону
Алексей Кормилкин пишет: Навскидку, у вас в компании чистый конвеер.
Но, с другой стороны, данное ''производство'' - позаказное. Может ли быть конвйерное производство заказных изделий?
Технический директор, Москва

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

Консультант, Ростов-на-Дону
Алексей Кормилкин пишет: Конвеер - эта методология, такая же как и проект, но имеющая большую непрерывность и плотность использования ресурсов.
С одной стороны, заказные большие партии однотипных автомобилей и заказные индивидуальные автомобили - всё-таки разные вещи. С другой, - действительно, дальнейшее уплотнение работ логично приводит к методологии конвейера. По-моему, конвейер не допускает простоев и ''окон'', - иначе он дезорганизуется . А может быть что-то третье? Например проектно-конвейерный подход (но только что это будет - еще надо проработать).
Технический директор, Москва
Гарник Кочарян пишет: С одной стороны, заказные большие партии однотипных автомобилей
Это как раз случай, описанный в статье. Отличия сайтов исключительно в дизайне (1 день работы дизайнера) и наполнения (1 день работы копипастера). Все остальное у этих сайтов одинаковое. Поэтому на мой взгляд, эта работа ближе к конвейеру.
Гарник Кочарян пишет: Например проектно-конвейерный подход
Возможно и такой подход. Гарник, я полагаю что возможны совершенно различные варианты, я предложил конвейер, Вы предложили скрестить конвейер с проектом, кто-то предложит еще что-то. Дискуссия только начинается. Уверен, появятся интересные варианты.
Директор по развитию, Москва
Гарник Кочарян, Алексей Кормилкин, Коллеги, проектно конвейерный (процессный) подход возможен, если удастся масштабировать локальный бизнес - в сетевой. Тогда вероятность простоев будет снижаться, если компания отдаст на аутсорсинг ряд своих функций, оставляя у себя только свои ключевые компетенции. Но при этом нужен единый интегрирующий процесс (стандарт) с которым согласны все участники. Мы уже пытались обсуждать такую модель бизнеса, в которой бизнес-единицами становятся сообщества профессионалов объединенных одним технологическим подходом для решения задачи.
Нач. отдела, зам. руководителя, Вологда
Алексей Кормилкин пишет: Это как раз случай, описанный в статье. Отличия сайтов исключительно в дизайне (1 день работы дизайнера) и наполнения (1 день работы копипастера). Все остальное у этих сайтов одинаковое. Поэтому на мой взгляд, эта работа ближе к конвейеру.
Я бы поспорил. Дизайн не единственное. Знаю много примеров, когда клиенты потом мучаются от подобных сайтов. Нет нормального виз.редактора, нельзя оптимизировать, сложно добавлять контент и т.п.
Технический директор, Москва
Олег Смирнов пишет: Я бы поспорил. Дизайн не единственное.
Олег, спорить лучше с автором статьи. Если я его правильно понял, то все отличия именно в дизайне и наполнении, именно поэтому они и продают сайты по 12 тыс. http://www.e-xecutive.ru/knowledge/announcement/1604018/ А потом, что мешает взять, например, Joomla. Добавить в нее десяток плагинов (JCE, FoxContact, Jcomments, Phoca, Blog calendar, Xmap......) и вот у вас уже достаточно мощная CMS в ''коробочном'' варианте, ничем не уступающая тому же Bitrix, только бесплатная во всех отношениях.
Оставлять комментарии могут только зарегистрированные пользователи
Статью прочитали
Обсуждение статей
Все комментарии
Дискуссии
Все дискуссии
HR-новости
Forbes опубликовал рейтинг лучших работодателей России

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

Опубликован рейтинг самых переоцененных профессий

Футболисты не на первом месте.

В Петербурге перенесли введение QR-кодов для кафе и отелей с 1 декабря на 27 декабря

Также власти планируют ввести дополнительные ограничения с 27 декабря до 9 января.

Россияне рассказали, что хотели бы получить в качестве корпоративного подарка

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