Все мы задумываемся о том, как нам открыть своё дело, как создать успешную компанию или что-нибудь грандиозное.
Могу сказать, однозначно, для того, чтобы сделать что-то большое и успешное, нужна хорошая команда. Но как создать такую команду? В данной статье я постараюсь раскрыть, как мы работаем со своей командой, и как благодаря совместным усилиям достигаем хороших результатов.
Первое, что хочется отметить — это большой набор публикаций на данную тему. Многие рассказывают о том, что нет готового рецепта и нужно пробовать. Ни могу с этим не согласиться. Нужно экспериментировать и даже больше скажу, нужно быть в чем-то первым, тогда может получиться синергия передового и эффективного подхода.
Я не буду писать про то, как находить правильных людей. Мне кажется, про это хорошо сказал Питер Тиль в одной из своих книжек. Суть заключается в том, что нам всем в команде нужны «орудия», а не просто «пули». Так как мы не можем всё контролировать, то должны быть люди, которые сами готовы выполнять сложные задачи и направлять за собой людей («пули»). Отталкиваясь от данного умозаключения, я бы хотел описать, как можно построить работу с «пулями».
В первую очередь, необходимо определиться проектная ли у вас работа, и как много отвлекающих факторов в проектах (суппорта-поддержки). Если приводить в пример компанию, в которой я работаю, то только проектной работой её назвать нельзя. Проекты достигли уже определенной зрелости и требуют поддержки, но так как мы в «вебе» (в сфере высоких технологий), нам необходимо развиваться. А это значит: заниматься поиском новых способов увеличения заказов на сайте, создавать единую и более технологичную платформу, внедрять более сложные и оптимизированные процессы в CRM для всего бизнеса, персонализировать рассылку и так далее. И логично возникает вопрос, как можно эффективным и простым путем достигать результатов в it-отделе? Ответ на данный вопрос простой: «команда». Команда должна очень четко понимать, какую задачу необходимо выполнять немедленно, а какая может подождать. Многие скажут, что за это отвечает менеджер. На мой взгляд, это не совсем верно.
Если мы обратимся к гибким методологиям, то увидим ситуацию, когда руководители уходят на второй план. Команда сама решает, что ей делать в первую очередь, а что оставить на потом. Мы даже можем заметь, что разработчик занимается не только написанием кода, но и тестированием, а иногда даже внедрением нового продукта. И это не плохо. Важно понимать, что команда — это живой организм, он сам развивается, а тот, кто не хочет расти с организмом, уходит на второй план или вообще выбывает из роста. На мой взгляд, сотрудники, которые не развиваются или развиваются в отличном направлении, в компании не нужны, они только будут тянуть всю компанию вниз. От таких людей нужно быстро избавляться.
Что же движет команду вперед? Конечно же, это идея. Каждая команда должна очень четко понимать, какая у компании миссия, и чего она хочет достичь. Поэтому первое, что нужно сделать — это обозначить команде простые и понятные идеи, которые будут разделять все сотрудники. Возникает резонный вопрос: а как запустить движение, ведь иногда одной идеи не достаточно? В данном случае нам помогают собрания один-два раза в месяц. Благодаря им все сотрудники узнают о том, каких результатов хочет достичь компания, и что для этого необходимо сделать.
Предлагаю вернуться к обсуждению команды. После того, как мы определились, что команда — это живой организм, который имеет идею, заставляющую двигаться всю компанию. Мы должны научиться выстраивать цели. Можно обратиться к простому методу SMART, про неё вы можете отдельно прочитать. Главное, чтобы цели были всем понятны и достижимы. Данные цели можно обсуждать один раз в неделю только со своей командой. Важно, чтобы каждый член команды знал, что собирается достичь сотрудник. Для того, чтобы эффективно достигать цели, мы должны быть чем-то ограничены. К примеру, нам очень подошел итерационный подход. Когда за определенный отрезок времени (у нас он составил неделю), каждый сотрудник должен показать результат, который поможет достичь цели.
Важно понимать, что задачи, которые приводят к достижению результата должны быть понятны, даже малышу. Тогда мы можем быть уверены, что результат хоть какой-то, но будет. Задачи, которые приводят к данному результату, должны быть разделены на более мелкие (декомпозиция) и приводить к конкретному ежедневному результату. Проверить результат можно на митингах (ежедневных собраниях), где каждый сотрудник по методологии SCRUM, даст ответ на три простых (а поначалу очень сложных) вопроса: Что я сделал с последнего собрания, чтобы достичь цели? Какие проблемы у меня возникли? Что я собираюсь сделать сегодня, чтобы успеть к концу итерации показать результат?
Обычно собрание состоит из группы не более 6 человек. Собрание не должно затягиваться более, чем на 20 минут. В случае если такая ситуация возникает, необходимо меньше времени уделять деталям. Лучше подойти отдельно к сотруднику и помочь ему разобраться с его текущими задачами. В нашей компании каждый сотрудник it-отдела может обратиться за помощью, и это приветствуется. Хороших эффект достигается при парном программировании. Задачи, которые обуждены на собрании записываются скрам-мастером каждому сотруднику отдельно в формате: «Что сделано:» и «Что будет сделано к следующему собранию». Мы используем Skype чат между скрам-мастером и сотрудником, чтобы данные записи были навиду у каждого участника команды и можно было быстро спросить про, что данная задача. Для того, чтобы сотрудники много не отвлекались на чаты и почты, мы ввели несколько простых правил:
- Совсем не пользуемся почтой (если пользуемся, то значит отдыхаем от задач (перерывы всем нужны, но лучше их потратить на чай));
- Отключаем уведомления в скайпе (команда: /alertsoff, скайп используем для разъяснения задачи, которую делаете, постановки срочной задачи);
- Используем команду /alertson [text] в важных скайп-чатах для того, что оперативно реагировать.
- Чтобы возможно было не пользоваться почтой, все обращения в it-отдел вначале обрабатываются it-менеджером. Многие задачи на этапе общения с заинтересованными лицами, так и не превращаются в задачи.
Задачи, которые выполняет каждый сотрудник команды фиксируются в треккере (мы используем worksection). Если менеджер или тот, кто ставит задачу (скрам-мастер, владелец продукта), не нашел времени её детализировать, то разработчику необходимо самостоятельно занести её треккер. Команда должна планировать свои задачи и знать, кто и за какие задачи отвечает. Для эффективного планирования, мы используем Google Docs, в котором каждый сотрудник может отфильтровать задачи по себе. На мой взгляд, каждый участник команды должен научиться оценивать свои задачи.
Для того, чтобы оценка имела реальный резонанс, она проставляется напротив каждой задачи. Оценка представляет из себя балл, который включает два признака: это важность для бизнеса и срок выполнения. Пример, если задача выполняется за 1 день по оценки команды (и сотрудника, который будет выполнять), значит данная задача весит 1 балл. Если задача очень важная для того, чтобы показать результат, то ей может быть дано от 0,1 и выше баллов, на усмотрение команды. Данный метод был взят из книги Расмуссон Дж. «Гибкое управление IT-проектами. Руководство для настоящих самураев» и начинает приносить свои плоды только в том случае, когда каждый участник команды понимает, на сколько важны данные баллы для команды. Есть сложность, когда каждый сотрудник будет хотеть получить наибольшее количество баллов и не будет выполнять другие важные задачи, например связанные с суппортом (подержкой текущих проектов). Во избежание таких случаев, мы ввели конкретное правило:
«Каждое утро проверяем треккер на наличие новых задач:
— задачи, которые можем закрыть в пределах 15 минут, закрываем сразу;
— задачи, которые не можем выполнить в пределах 15 минут обсуждаем на собрании.»
Данное правило позволило легко выявлять важные задачи и давать за них больше баллов.
В итоге мы получили полный контроль над своими сотрудники, при этом каждый знает, на сколько он эффективен и каких результатов команда хочет добиться. В следующей статье я постараюсь более подробно раскрыть наши результаты и сложности, перед которыми мы столкнулись.
Автор: Okrema
