Сегодня мы с вами поговорим про производительность – я думаю, что это тот показатель, который нам всем надо каким-то образом повышать.
Меня зовут Андрей Акулов, я уже больше 15 лет работаю в полях, внедряю различные системы на платформе 1С. Последние 10 лет работал в качестве системного архитектора – на проектах оборонки, на крупных предприятиях, в интеграторах (Microsoft, IBS, Астерос). За все это время накопилось много интересного. Но сейчас мы с вами поговорим о производительности.
Классическое определение производительности – это количество в единицу времени. Но, к сожалению, оно к нам не подходит.
Нам необходимо еще учитывать такие три показателя, как:
- ресурсы;
- объем и сложность задач;
- и управление проектом и архитектурой.
Давайте попробуем с вами разобрать каждый из этих критериев и в конце определить, что же реально влияет на производительность, и за счет чего мы можем зарабатывать больше, затрачивая в ходе управления задачами и проектом меньшее количество наших ресурсов.
Ресурсы
Давайте возьмем три критерия, которые определяют наши ресурсы. Это:
- стоимость;
- проектная роль;
- и функции, которые выполняет наш специалист.
Соответственно:
- условная стоимость проекта – от 1500 руб/час до 3500 руб/час;
- проектная роль – стажер, консультант, программист, архитектор;
- функции – от тестирования до определения стратегических целей.
Попробуем определить, что у нас определяет баланс.
Например, возьмем, стажера – он нам обходится в 1500 рублей в час, может выполнять тестирование и документирование продукта.
Берем такого специалиста? В принципе, да. Немного дороговато, но нормально.
А если мы ему добавим функций – предложим покодировать и попроектировать?
Эта история уже выглядит сомнительно, и мы точно уже понимаем заранее, что стажер именно в плане функциональности, которую мы ему поручаем, будет использоваться неэффективно.
Давайте посмотрим другую ситуацию – тот же стажер, но мы его закупаем по 3500. И при этом говорим: «Ты у нас будешь только тестировать и писать документацию». Как вы считаете, адекватная схема? Я думаю, что нет.
Идем дальше – давайте рассмотрим позицию программиста. Итак, мы закупаем программиста за 1500, говорим, что он программист, который занимается только кодированием. Отличная история. Он программирует и все, на что нам с вами нужно уделить дальнейшее внимание, это – организовать ему именно кодирование. Как он кодирует, с какой скоростью, сколько ему задач даем, и какими задачами он будет управлять.
А если мы берем программиста, ставим ему закупочную цену 3500 и говорим ему, чтобы он за 3500 не только кодировал, но еще и документацию писал.
Честно говоря, я бы так со своими специалистами поступать не стал, потому что я специалисту за высокую ставку предлагаю выполнять неквалифицированную функциональность (с точки зрения его ставки).
Другая история – программист ко мне приходит и говорит: «Я стою 3500». И я понимаю, что за 3500 я могу его кинуть на отдельное направление, дать ему самые сложные проблемы, самые сложные задачи, которые вызывают у меня постоянную головную боль. Я ему говорю: «Возьми это направление, определись с концепцией, спроектируй, реши, куда ты будешь двигаться, и реши эту проблему – сам закодируй».
Возникает вопрос – что в этой схеме лишнее (относительно функциональности, которую мы предлагаем за 3500)?
При таком подходе кодирование лишнее. Он все-таки больше занимается концепцией и проектированием, либо собственно кодированием. Кодирование в данном случае немного выползает. Это программист, который уже может выполнять функции архитектора. Но если у вас с какой-то темой очень плохо, тогда – да. Берем, платим, сколько он скажет, и мы точно будем знать, что он эту проблему решит.
Посмотрим архитектора. Допустим, ставка архитектора, по которой мы его покупаем – 3000 рублей. И при этом он и концепцию разрабатывает, и проектирует, и даже кодирует.
Если он недавно перешел из разряда программистов в архитекторы и стал уметь самостоятельно вести направление и даже целый проект, то кодирование – это прикольно, мне тоже нравится кодировать, я умею и люблю программировать, это доставляет мне огромное удовольствие, но, к сожалению, на проекте это уже начинает выглядеть очень неэффективно.
Да, мы можем сделать какую-то узловую точку и получить удовольствие, но когда я кодирую, лучше, чтобы вокруг меня никого не было. В результате теряется координация работ других специалистов.
Поэтому если смотрим архитектора, то функцию кодирования нужно куда-то передавать. Именно делегировать.
Отсюда делаем несколько простых выводов – уровень ставки определяет:
- баланс роли и функции;
- требования к тому, как вы будете управлять специалистом – если у него ставка высокая, то вы ему и задачи будете давать наиболее сложные;
- и требования к самой задаче – какие задачи можно давать специалисту за такую стоимость.
Четыре подхода к решению задач
Теперь определим, какие бывают задачи, и что с ними дальше делать.
Задача (или решение проблемы) – это процесс. Мы с вами являемся специалистами, организующими производственный процесс по переводу проблемы в решение. Соответственно, этот процесс можно организовать по-разному.
Рассмотрим для примера четыре истории:
- специалист работает в штате;
- некий проектный офис;
- структура интегратора;
- и некая штабная структура по решению проблемы.
Итак, красной точкой обозначена проблема.
- Первая ситуация – программист в штате. У него есть проблема, и программист, работая в штате, успешно с ней справляется. При таком подходе развитие, как правило, не идет. Мы с вами можем только поддерживать на достаточно высоком уровне саму целостность системы. С развитием здесь у нас будет не все хорошо.
- В проектном офисе у нас появляется позиция архитектора и несколько руководителей проектов или подразделений, которые объединяют в себе ресурсы. При этом несколько проектов выполняется параллельно. В данной картине идет борьба за каждый ресурс – программисты выделены в отдельный отдел разработки, и чтобы получить к ним доступ, нужно:
- договориться со своим руководителем проекта,
- договориться с руководителем отдела, где находятся программисты.
- договориться с отделом, где находятся консультанты
- попробовать всех этих людей в своем проекте объединить и на этом заработать.
- Следующий пример – интегратор. Здесь у нас появляется еще несколько уровней. Появляются кураторы, директора проектов, отдельные структурные подразделения, отделы, которые объединяют в себе функциональных специалистов, например, специалисты, методисты, которые занимаются только бухгалтерским/налоговым учетом. Соответственно, чтобы получить оттуда специалиста, вы должны его закупить, поэтому бюджет проекта делится между всеми отделами, где вы берете ресурсы.
- Последняя структура – т.н. штабная. К ней мы пришли не так давно, буквально в последние два года. В штабной структуре у вас есть одно лицо, которое принимает решения по проекту, и есть ресурсы, которые находятся в его прямом подчинении.
Чем штабная структура отличается от всех остальных? Она заточена под решение задач или проблем, которые однозначно возникнут в известное время.
- Например, вы заходите на проект сегодня, а через месяц у вас сдача НДС. Система не готова, проблема с разработкой, с методологией, много других проблем. А ситуацию нужно решить ровно через месяц, чтобы компания сдала НДС.
- Другая ситуация – компания запускает какой-то объект, допустим, космодром, на открытие приедет высокое лицо, и нужно сделать так, чтобы к его приезду все работало.
- Еще одна ситуация – через неделю (максимум через две) ожидается приход большой воды, которая может залить какой-то важный объект. И за эту неделю нужно сделать все, чтобы эту ситуацию купировать.
В таких ситуациях не работают Agile-методы, не работают каскадные методы. Здесь работает штабная модель, ближайшая аналогия которой – структура МЧС, военные структуры, где как раз разворачивается штаб, разворачиваются ресурсы, и объем закрываемых задач или проблем ограничивается только наличием у вас ресурсов. Поэтому когда вам по телевизору говорят, что под такую-то ситуацию выделено столько-то единиц техники, столько-то людей привлечено, все говорят, какие ресурсы выделены для решения таких задач. Это сделано для того, чтобы гарантировать, что эта задача или проблема будет купирована.
С этого момента мы будем говорить именно о штабной структуре. Программист в штате, проектный офис и интегратор – это все хорошо, но долго и не всегда эффективно.
Классификация задач
Руководители проектов почему-то очень любят произносить тезис «Хаос нельзя автоматизировать». И кичатся этим, говоря заказчикам, что автоматизировать их хаос невозможно. Но это ложный тезис, потому что существует достаточно простая методика по решению проблемы хаоса задач.
Простой пример – вы заходите на предприятие и знаете, что у них проблема с выполнением заявок. Допустим, сейчас на блоке «Техническая поддержка» в трекере висит 1500 задач, и при этом через месяц должен быть сдан НДС, или компания должна открыть филиалы, или перейти с автоматизации каждого филиала по отдельности на централизованную структуру автоматизации. Сроки известны, бюджеты выделены, к этому нужно успеть подготовиться, но при этом задач у вас однозначно больше, чем вы можете сделать (подразумевается, что у вас ограниченное количество ресурсов). Что будем делать?
Как ориентироваться в этих огромных системах HelpDesk или Excel-табличках, где перечислено несколько тысяч задач в огромном списке?
В данном случае я обращаюсь к специалистам, архитекторам, руководителям проектов – берете все задачи и делите их ровно на три блока (три классификатора):
- тип задачи: ошибка, консультация, разработка;
- к какому функциональному блоку задача относится: продажи, производство, склад;
- какой объект метаданных генерирует эту ошибку.
Вы не должны решать каждую задачу по отдельности – прежде чем решать задачи, вам нужно классифицировать их. Такая классификация на уровне 1500 задач проводится примерно за выходные дни. В пятницу вы садитесь за этот список – у вас еще хаос в голове, за выходные вы проводите классификацию по трем критериям, в понедельник вы уже знаете проблемные точки, куда нужно будет бросить ресурсы.
Вам не нужно кидать ваших разработчиков на решение разноплановых задач – определяете приоритетный функциональный блок:
- например, если бизнес вашего клиента – это продавать и отгружать, то первое, что нужно сделать – это накинуться на блок «Продажи» и купировать проблему с документом «Заказ клиента»;
- после этого мы анализируем список задач и понимаем, что у нас есть еще отдельный процесс (например, маркировка обуви), который вообще непонятно, как делать, но он затрагивает всю компанию. Значит, ставим на это направление отдельного человека, и пускай он им аккуратно занимается.
В результате у вас вместо хаоса получается вполне понимаемая система для принятия решений.
Здесь показан метод классификации. Я не буду подробно на нем останавливаться. Смысл в том, что у вас на входе есть некий список задач:
- вы эти задачи классифицируете – ошибка/разработка/консультация или проект;
- внутри каждого блока вы задачи классифицируете уже более детально – и на каждую отдельную составляющую выделяете ресурсы;
- если ресурсов на это у вас нет, то хотя бы определите, какой объект метаданных генерирует ошибку. Если вы обнаружите, что у вас из месяца в месяц, из недели в неделю возникают одни и те же ошибки, может, стоит посмотреть в исходную ситуацию – что же там такое происходит, что заказ клиента постоянно генерирует нам ошибку.
Сравнение методик управления проектом
Есть несколько методик управления проектом. Выделяют две:
- каскадная;
- и различные варианты гибких Agile-методик – Scrum, Kanban и т.д.
Каскадная модель предполагает последовательное выполнение этапов проекта и много документации, которая долго делается, согласовывается и не всегда доходит до реализации. Но при этом все заняты. Вот такая очень затратная, медленная и совсем не гибкая модель.
Вариант с Agile подразумевает, что мы делим разработку на отдельные периоды (двухнедельные или больше), внутри каждого определяем список задач, и в течение недели проводим анализ, берем задачи в работу и отдаем сделанную функциональность заказчику. Модель не самая плохая, но она тоже не имеет определенных сроков и предполагает, что этот ужас может длиться без конца – таких двухнедельных периодов вы можете нарезать сколько угодно
Давайте посмотрим, как работает штабная модель. Она работает следующим образом:
- вы на вход получаете список структурированных проблем и задач;
- у вас есть срок, причем такой срок, который горит, и который никак нельзя превысить и нарушить;
- у вас есть рабочая группа с лидером, который внутри рабочей группы определяет, как вы будете решать эти задачи – куда будут кидаться ресурсы;
- соответственно, у вас на выходе рождается определенное количество релизов.
Мы доходили до того, что когда идет внедрение, релизы могут рождаться каждый час – т.е. информационная система компании-заказчика постоянно находится в режиме изменения. С одной стороны, сотрудники заказчика к этому очень быстро привыкают, потому что понимают, что у них тут же все исправляется, функциональность добавляется. Но это требует от них определенных усилий, поэтому работа в таком форс-мажорном состоянии длительное время чревата увольнением сотрудников у самих заказчиков.
Особенности управления проектом при штабной модели
Давайте попробуем определить, какие требования у нас будут предъявляться к управлению проектом.
Итак, у нас есть ресурсы, у которых есть:
- стоимость;
- проектная роль;
- функциональность.
У нас есть классифицированные по типам задачи, отсортированные по трем критериям:
- владелец проблемы;
- срочность;
- важность
Владелец проблемы стоит на первом месте. Неправильно классифицировать задачи только по важности и срочности. Гораздо важнее то, у кого находятся ваши деньги. Если у вас есть задачи и от финансового директора, и от руководителя отдела склада – тут очевидно, куда следует направить ресурсы. Но если со склада нельзя отгрузить, и клиент из-за этого начинает терять деньги, вам уже нужно будет договариваться о приоритетах с руководством заказчика.
Итак, мы с вами выбрали некую штабную модель управления проектом, и теперь нам нужно определить, как мы всем этим будем управлять:
- нам важно быстро принимать решения;
- у нас нет времени на написание ТЗ;
- при этом нам необходимо иметь всю необходимую информацию, даже если мы постоянно находимся в режиме неопределенности – не знаем, какие задачи прилетят завтра, не знаем, как наши действия повлияют на дальнейший ход событий;
- для этого важно, чтобы заказчик и исполнитель все время работали вместе – не получится так, что вы получили задачу, ушли, а потом через месяц пришли, внедрили и все круто – вы каждый день в режиме 24/7 находитесь в процессе решения проблем заказчика;
- естественно, при таком подходе никакой демократии быть не может.
Какие требования мы выделяем к управлению проектом:
- наличие заказчика с проблемой;
- наличие командира со стороны исполнителя;
- организация самого штаба на объекте заказчика или на каждом объекте, который подпадает под ваш периметр автоматизации;
- и простой инструмент коммуникации для управления самим проектом.
Управление задачами при штабной модели
На слайде показан пример того, как мы проводим первичную стратегическую сессию и определяем объем проекта. Мы собираемся с заказчиком и начинаем рисовать процессы на стене с помощью стикеров.
- синие стикеры определяют группу процессов;
- зеленые стикеры определяют функциональность, которая должна выполняться – даже если мы не знаем, как эту функциональность реализовать, но знаем, что там есть или может появиться какая-то проблема, мы это сразу обозначаем.
На стикеры мы вешаем закладки по светофорному принципу:
- красным мы отмечаем стикеры, соответствующие нерешенным проблемам (в самом начале пути все стикеры помечены красными закладками);
- когда мы какую-то функциональность уже реализовали, и она у нас находится в режиме тестирования, мы меняем закладку – наклеиваем желтую;
- и когда проблема уже решена, мы наклеиваем на стикер зеленую закладку.
Эти закладки мы называем индикаторами.
После того как мы определили проблемы, эта картина у нас висит с первого дня и практически до конца проекта. Она очень редко меняется – на ней могут только меняться индикаторы.
При этом не пишется отдельная документация, расписывающая, как мы будем делать то или другое. Предполагается, что мы просто берем очередной проблемный стикер и реализуем соответствующую ему функциональность.
Организация штаба
На слайде показано, как организован наш штаб:
- заказчик предоставляет нам помещение с необходимым количеством компьютеров / мониторов (или мы сами их привозим – как договоримся);
- все стены в помещении мы заклеиваем бумажками;
- и, соответственно, внутри мы проводим некие стратегические сессии, где определяем, какое у нас ближайшее направление развития.
Даже если я, например, нахожусь в Москве, а объект заказчика находится, скажем, в Воронеже, в Калуге или еще где-то. При этом мы настаиваем, чтобы заказчик выделил нам помещение, где никого кроме нас не будет, чтобы мы в любой момент могли туда приехать, и это помещение нас ждало.
Мы выставляем требование – нам нужны вторые мониторы и беспрепятственный доступ на территорию в режиме 24/7. Мы создаем условия для того, чтобы оперативно решать проблемы. Если нам нужно выехать сегодня, у нас с этим проблем никогда не бывает.
Мы уже давно работаем в этом режиме – взяли, накинулись, проблему решили, идем дальше. Находиться в офисе и спокойно пить кофе у нас не получается.
Организация коммуникаций
Теперь – как мы всем этим управляем.
Поскольку большая часть сотрудников у нас работает удаленно, мы в качестве инструмента управления людьми для себя выбрали мессенджер Discord.
Кружки слева – это наши проекты. Для выделенного проекта мы видим группы обсуждений, которые к нему относятся.
Все планирование и подтверждение итогов по проекту у нас проходит в отдельной группе «планерка». На слайде показаны сообщения в этой группе – здесь специалисты пишут план работы на день и в конце дня пишут некий итог. Этого достаточно. Если специалист по итогам дня у меня здесь не отчитался, я ему ставлю двухдневный штраф.
У нас нет бюрократии, нет совещаний, за счет этого мы не тратим время.
Мы для себя выработали определенные правила. В чате одновременно находятся и сотрудники исполнителя, и сотрудники заказчика, в том числе, лица принимающие решения – владельцы, генеральные директора, руководители подразделений. Сотрудники заказчика не вмешиваются в оперативное управление, ничего не пишут в чате – они не могут ставить задачи специалистам, могут просто наблюдать. Это приводит к очень интересным результатам.
Когда программист долгое время не проявляет активности, у всех сразу возникает подозрение – чем он занимается? Либо он пошел по неправильному пути и начинает разрабатывать что-то не то. Либо он ушел, либо он занимается чем-то другим. В определенный момент все начинают привыкать к тому, что чат – это отдельная жизнь. И если в чате долго нет активности, у всех это вызывает огромное подозрение. У нас есть внутреннее правило – каждый специалист должен не чаще чем раз в 15 минут сделать публикацию в чате.
Я уже говорил, что мы делим чат по проектам и по темам.
На слайде показан пример коммуникации по проекту, когда мы готовим объект заказчика к запуску. Это один день из жизни нашей команды – здесь вы можете посмотреть, как мы проводим коммуникации с командой. Видно, какие проблемы возникают, как мы их решаем.
Это – живое общение, решение проблем. Причем проблемы могут прилетать абсолютно неожиданные.
Тем не менее, мы за тот день полностью подготовили объект заказчика к внедрению.
Здесь мы выкладываем скриншоты, обсуждаем разработку.
При этом постановка задачи программисту проводится примерно так:
- у меня в голове есть некая картина, как это будет выглядеть, я примерно понимаю первые шаги, которые нужно сделать разработчику, и формулирую эти шаги в обсуждении;
- он их делает и выкладывает в обсуждение результат в виде скриншота;
- мы вместе смотрим, что получилось, и ставим следующую задачу.
У нас никогда разработчик не работает по некоему заданию – не бывает такого, что дали ему задание, и он ушел с ним работать.
Если разработчик к нам приходит, мы постоянно видим его результат работы. При этом мы достаточно гибкие. У нас есть свои разработчики и те, кто к нам приходит. Поэтому если хотите поучаствовать в наших проектах, обращайтесь ко мне – мы договоримся.
****************
Данная статья написана по итогам доклада (видео), прочитанного на конференции INFOSTART EVENT 2019.
