Компания
145,30
рейтинг
14 июня 2012 в 10:55

Разное → Оптимизация работы веб-студии. Применение теории ограничений в производстве сайтов



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

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

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

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


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

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

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


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



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

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

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

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

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

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


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

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



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

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

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

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

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

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

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

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



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

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

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

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

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

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

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



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

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

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

Резюме


Кратко резюмируем подход по непрерывному улучшению потокового производства.
  1. Первый шаг — найти ограничение системы. Что в настоящий момент задает ее максимальную производительность?
  2. Второй шаг — оптимизировать ограничение системы. Добиться максимуму от узкого звена без дополнительных инвестиций.
  3. Шаг третий — подчинить скорость всего производства скорости работы узкого звена.
  4. Четвертый шаг — расширить узкое звено.
  5. Шаг пять — вернуться к первому шагу, но помнить об инерции

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

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

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

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

Василий Чуранов и команда web-canape.ru
Автор: @vasyay
WebCanape
рейтинг 145,30

Комментарии (38)

  • +3
    Спасибо за очередной интересный и хороший пост, слежу за вами уже давно
    А когда примерно будет ваша система документооборота в публичном доступе?
    • +3
      Спасибо за отзыв. Сейчас мы научились по ряду параметров осуществлять мониторинг работы, что бы оценивать насколько хорошо работает произвоство. Это внедрим в систему и выпустим. Планируем на конец лета.
      • 0
        Будем ждать, она представляет большой интерес
  • +8
    Статья, безусловно, очень интересная. Знаю немало людей, которые пытаются сейчас выстроить нечто подобное.

    Я же всегда при разговорах на подобную тему высказывался, что пользы от сайтов, произведенных по такой схеме, практически никакой нет. Максимум они годятся для неких пилотных проектов, чтобы просто нащупать почву в интернете. Но и это спорно. Поэтому жду с нетерпением статьи с небольшим анализом реальной пользы таких сайтов.
    • +2
      Спасибо. Мне самому этот вопрос постоянно не дает покоя. Насколько решения, которые получаются на конвейере хуже/лучше с точки зрения пользы для клиента. Пока то, что мы наблюдаем — меня вдохновляет. Анализ обязательно сделаем. Почти все готово для этого.
      • 0
        Единственный минус, который я вижу — нехватка «индивидуальности» и «эксклюзивности». По крайне мере если бы я пытался конкурировать, то упирал бы на это. Достаточно большой процент клиентов хотят выделиться и конвейер будет вызывать отторжение у них.

        Полезность сайта для клиента вряд ли будет ниже, чем у прочих в этой ценовой категории. Это уже будет зависеть от самого клиента. Если сайтом заниматься — то наверняка будут поступать заказы на доработку, изменение, расширение функционала. И их, вполне возможно, придется обрабатывать вне конвейера.
        • +2
          Сайты действительно сделаны по одной информационной сетке. Но посмотрите портфолио. Разве эти сайты можно назвать шаблонными? Каждому клиенту отрисовывается индивидуальный дизайн в рамках трех-колоночной информационной сетки. Сайты не похожи по визуалу друг на друга.

          Насчет полезности. Мы выпускаем сайты уже полностью наполненные текстами (для этого в команде есть копирайтеры) и заполняем метатеги для всех ключевых страниц. Соответственно после запуска сайт уже готов для приему посетителей и к индексации поисковыми системами :) Опробовав сайт в таком виде и получив отклик, клиенту действительно потом приходят за доработками и расширением функционала. Этим уже занимается наша служба поддержки. Но в большинстве случаев функционал заложенный в нашей стандартной админке подходит 80% клиентам без дополнений
          • +2
            Это больше вопрос позиционирования. Я посмотрел уже в портфолио и согласен — это именно то, что нужно людям. Другое дело что люди сами зачастую не знают, чего они хотят и скрывают это за самыми разными ярлыками. В том числе и «эксклюзивность». На этом вполне можно сыграть. Хотя я не уверен что случится раньше — закончатся клиенты или вы больше не сможете найти персонал для увеличения мощности конвейера :)

            Через год такими темпами у вас будет уже 500 сделанных сайтов. Через два года — уже больше 1000. Из них, я думаю. 1-3% будут обращаться за нестандартными доработками достаточно регулярно. И тут уже можно будет столкнуться с проблемами расширяемости стандартного движка.
    • +5
      Я не знаю никого, кто может выпустить пилотный проект за 5 дней и 12 тысяч рублей. Мне кажется это просто оху… великолепно.
    • +2
      А я бы хотел побольше таких сайтов в рунете. Зачастую мне нужно от сайта той или иной конторы только: действующие контакты, описание услуг или каталог товаров (обязательно с ценами), режим работы. Т.е. просто актуальная информация о конторе. В принципе и все, большего нафиг не нужно. Но в рунете как раз большая проблема с сайтами данного класса. Если я хочу товар А и хочу узнать, где в округе он есть, то я не могу получить информацию об этом. По крайне мере в Самаре ситуация обстоит именно так. Есть конечно разные сайты агрегаторы, но информация на них как правило устаревшая.
  • 0
    Не хватает самой книги. Или двух-трёх.
    1-я. онлайн, DOC, PDF. (Есть 2 перевода.)
  • 0
    Дизайн, как я понимаю, вы не согласовываете с заказчиком?
    • 0
      Согласуем. На это есть 1-3 дня. Как правило этого достаточно, если хороший дизайн и проведена предварительная работа с клиентом (на этапе «сбор информации»). Естественно есть и такие, кто согласует долго и нужно, но их не много.
      • 0
        И следующий проект, дизайнер не начинает рисовать, пока по текущий не утвердили? Или все же идет наложение новых проектов и правок по старым проектам?

        Просто этого не избежать, всегда есть «текучка» по проектам (дизайн, программинг или контент). Интересно, как вы вставляете эти задачи в ваш конвеер?
        • 0
          Конечно начинает. Пока менеджер согласует дизайн, дизайнер делает правки или рисует новый сайт. Менеджерам сложно держать под контролем много проектов. Тут им помогает система, которая расставляет приоритеты, каким проектом сейчас заниматься. Приоритеты расставляются исходя из дней затраченных на проект и их статусов.
  • 0
    Вопрос автору: почему не хотите предлагать клиентам свой хостинг? Клиенты же любят «под ключ». И вам лишний постоянный фоновый поток денег не помешает. Не хотите держать в штате администратора — отдайте на аутсорс или партнерам: получать копеечку агентских платежей, знать заранее параметры хостинга и иметь с контакт — всяко лучше, чем с «экзотик-хостами» бодаться… Опять же — такое бодание должно стоить денег, ИМХО.
    • +1
      Хостинг это вообще хороший вариант, у многих хостинговых компаний есть партнерки
      Сам так делаю, 20% от стоимости мои, а вся ответственность и тех поддержка на них
    • 0
      Хотим и предлагаем ) Многие приходят со своим хостингом и вот с ними сложности при выкладке.
  • 0
    очень похоже на Кайдзен
  • +6
    Очень впечатлили следующие шаги-действия:
    — нет смысла повышать производительность отдельно взятого участка, вместо этого улучшаем только слабое звено
    — параллельные проекты затягивают срок на всех проектах сразу
    — вынесение проблемных этапов на период «до начала работ» — вообще суперход!

    Кому-то может показаться и банальным, но меня сильно впечатлило! Спасибо! Буду думать, как бы внедрить :)
    • 0
      Тогда почитайте обязательно «Цель» Элияху Голдрата (ссылки чуть выше), она разорвет вам все шаблоны :-)
  • 0
    спасибо за то, что поделились своим опытом.
    у меня возникло 2 вопроса:
    1. почему буферы стоят там где стоят? — возникает ощущение, что надо было забить пустое место :) Буфер обычно ставят перед слабым звеном
    2. канбан на ваш конвейер хорошо бы лег. есть мысли по его внедрению?
    • 0
      Согласен, если делать схемку по правилам, то буферы ставятся перед узким звеном. В данном случае мы страхуем дизайн и контент (после сбора информации). Для наглядности нарисовал буферы после, что бы было понятно, что необходимо время на согласование.

      По канбану пока детально не изучал эту тему. Сейчас собираем детальную статистику за несколько месяцев по всем операциям на конвейере, что бы был виден срез всего производства (в том числе документооборота). Изменения пока больше вносим по интуиции, эксперементируем, смотрим на результат.
  • +1
    Странно, что проблему сбора информации вы не обнаружили раньше. Как показывает практика — предоставленные материалы в полном объеме, качестве и в срок — большая редкость.
    • 0
      Проблему мы знали, но не предполагали, что ее устранение так сильно расширит производство.
  • +1
    Если не слышали про Kанбан, возможно будет интересно. Вы его реализовали - www.infoq.com/resource/news/2010/01/kanban-scrum-minibook/en/resources/KanbanAndScrum-Russian.pdf
    • 0
      не соглашусь, я сначала тоже обрадовался, но вытягивания тут нет пока
      далеко не каждая полосатая доска является доской канбан
  • +1
    Судя по третьему изображению, на нем 7 человек, вы восьмой? По сравнению со вторым изображение появился человек отвечающий за выкладку.

    А какая взаимозаменяемость у каждого сотрудника, ну в случае отпуска, травмы (тьфу тьфу тьфу) или увольнения.

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

    Допустим у такой цепи есть некая пропускающая способность, но как если надо будет делать на 2-3-4 проекта больше? Вводить новую такую же цепь? Делать сеть?
  • +1
    Да я и не против, но дух Канбан тут присутствует.
    Просто хотел поделиться статьей.
    Она короткая и доходчивая.
    • 0
      Что-то  промазал, что-ли. Это было к realno.
  • НЛО прилетело и опубликовало эту надпись здесь
  • 0
    интуитивно мне кажется, что у вас сотрудники загружены неравномерно. Например, в прошлой статье вы писали, что программист тратит 2 часа на доделку сайта, а контент делается 5. А чем программист занимается в остальное время? У него есть другие обязанности?
    • +1
      Излишки ресурсов — это нормально. ) Неравномерная загрузка — тоже норма, с которой можно и нужно работать. Когда все работают на 100% — начинается бардак.
  • 0
    Кузнец Владимир Пименов?
  • 0
    Демо входа в вашу CMS нет?
  • НЛО прилетело и опубликовало эту надпись здесь
  • 0
    А кто для вашего сайта web-canape.ru пишет тексты? Не только тексты, а вообще, кто планирует расположения контента на сайте, придумывает сам контент (таблицы, картинки, текст). Анализируете ли посетителей на сайте, откуда куда идут, на какой странице застревают (счетчики, вебвизор)?

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

Самое читаемое Разное