Инфраструктура и управление в проектном бизнесе

Заказчикам 6 июля 2022 г.

Привет, меня зовут Кирилл, я CEO WB—Tech. В статье расскажу про инфраструктуру в компании и подходы для эффективного управления проектами.

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

Инфраструктура и управление в проектном бизнесе

Предыстория
Human Resources
Управление персоналом и коммуникация в команде
Рекрутинг
Процессы: управление и улучшение
Постановка и выполнение рабочих задач
Бухгалтерия и финансы
Учет времени
Прибыльность бизнеса
Производство и консалтинг
Вместо резюме

Предыстория

С 2011 по 2016 год дела в компании шли отлично — были большие проекты и ежегодный прирост в выручке. Финансы я вел в таблице, вручную вбивая все расходы и доходы.

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

Любой компании необходимы финансовый директор и система учета, так как СЕО компании — не вездесущая персона. Невозможно более чем по 20 сотрудникам вручную разбивать транзакции по всем доходно-расходным статьям.

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

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

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

Human Resources

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

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

Аутсорс-разработка как бизнес: какая должна быть команда, чтобы дела шли хорошо

Управление персоналом и коммуникация в команде

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

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

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

Мониторим удаленную работу, не нарушая личных границ сотрудников

Мы знаем, работа не может состоять только из выполнения задач, на практике нельзя отработать 40 часов, не поднимая головы. Поэтому соблюдаем принцип — 32 часа на задачи и 8 часов на разговоры, чтение статей, чай с коллегами, покурить и др. Такой подход позволяет сотруднику честно логировать свое рабочее время — картина подсчета становится четче, учитываются многие моменты в денежном эквиваленте. Без этого мы не смогли бы достигнуть цели — расчета реальной стоимости проекта.

Мы также за любое общение в команде, и стараемся, чтобы все друг друга знали и дружили. У нас есть правила оформления профиля в Slack и всегда доступный Офис в Zoom.

Наш корпоративный Slack. В общем канале прилинкована комната-офис в Zoom, а справа — пример оптимального заполнения профиля участника сервиса.

Наш корпоративный Slack. В общем канале прилинкована комната-офис в Zoom, а справа — пример оптимального заполнения профиля участника сервиса.

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

Например, неправильно, если сотрудник пишет так.

Неправильно, если сотрудник пишет так.

Сообщение должно быть адресовано человеку, а также содержать контекст и вопрос/просьбу.

Сообщение должно быть адресовано человеку, а также содержать контекст и вопрос/просьбу.

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

Все эти регламенты и процессы являются частью системы: корректное заполнение профиля в Slack важно, потому что участвует в связке Slack-Jira-Финолог (система финансового учета), а внедрение новичка в команду включает в себя процессы по документообороту.

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

Рекрутинг

Онбординг является продолжение рекрутинга. Мы научились хорошо подбирать сотрудников под проекты, сформировали воронку для предсказуемого рекрутинга и с 2021 года ищем IT-специалистов в сторонние компании.

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

Автоматизировали рекрутинг: HR начал быстрее находить крутых специалистов

Предсказуемый рекрутинг — это сколько стоит увольнение и найм нового сотрудника.

Процессы: управление и улучшение

Для эффективного управления важны стандарты качества, такие как регламенты, чек-листы, скрипты и правила. Они должны быть нативно включены в обычную деятельность сотрудника — все полезные для работы ссылки должны располагаться в интуитивно понятных и видных местах. А повторяющиеся действия из проекта в проект нужно автоматизировать.

Постановка и выполнение рабочих задач

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

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

  1. Как сейчас сделано/работает? Если задача подразумевает создание чего-то абсолютно нового, пункт можно пропустить.
    Описать общий контекст, чтобы исполнитель понял о чем речь — даже очевидные вам вещи могут быть неочевидны исполнителю или вам самим через месяц, когда придется по какой-то причине вернуться к задаче.
  2. Какая проблема? Описать, что не устраивает в существующей реализации — это причина постановки задачи.
  3. Как должно стать? Это сама задача. Нужно описать результат, при достижении которого можно закрыть задачу. И описать смысл задачи, чтобы исполнитель понял, зачем мы это делаем. Нам нужна не дырка в стене, а висящая полка, куда сложены книги.
  4. Как это сделать? Если на этот вопрос может ответить только сам исполнитель, тогда можно пропустить пункт.

sdsfg

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

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

Когда планируешь свою работу на спринт и на ближайшие 4 часа, то точно знаешь, что будет результатом деятельности.

Мы отлично разобрались с продуктами Atlassian, что уже несколько лет настраиваем их для других компаний с проектным бизнесом и ведем блог про то, как работать в этой сложной системе (про сущности Jira, автоматизации и Jira Service Desk).

Бухгалтерия и финансы

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

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

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

Улучшение — вечный процесс. Мы просто движемся по этому пути и делаем то, что встречается.

Учет времени

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

Мы занялись этим процессом 3 года назад. Сначала думали, что нам будет просто достаточно распределять по проектам задачи.

Например, у сотрудника Никиты в этом месяце на проект Арендоход ушло 80 часов, на Debug Mail — 60 часов, на Биомолекулу и Ульяну Сергеенко — по 10 часов. Исходя из этого, можем подсчитать рентабельность работ. Но оказалось, что это не так и такого соотнесения недостаточно.

Связано это со спецификой проектного бизнеса — кто-то платит нам фикс/абонентку, кто-то по часовой ставке, кому-то мы делаем проект по конкретным дедлайнам. А есть заказчики, у которых есть абонентка и дополнительно оплачиваемые проектные работы.

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

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

Отсюда появилась наша система управленческого учета. Мы долго ее делали, т.к. на рынке нет готового решения. Во многом Финолог был создан с такой идеей, но в реальности — мы интегрировали Финолог с таск-менеджером, Google Формами и Таблицами, чтобы учитывались все данные: расчет з/п сотрудника, постоянные и переменные расходы, отпускные и выходные, рабочие часы по проектам и др.

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

Прибыльность бизнеса

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

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

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

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

Производство и консалтинг

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

Хорошая команда рассчитывает сроки проектов с учетом рисков.

Хорошая команда рассчитывает сроки проектов с учетом рисков.

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

Вместо резюме

Если мой опыт был вам полезен, посмотрите остальные мои статьи. Часть материалов публикую здесь, часть на других площадках. Чтобы ничего не пропустить, подписывайтесь на страницу в Facebook. Публикую там все анонсы. А если хотите обсудить ваш бизнес, напишите нам.


Подпишитесь на блог WB—Tech

Никакого спама, только анонсы новых статей!

Кирилл Гришанин

Последние 10 лет руковожу командой аналитиков, дизайнеров и разработчиков