Про цели

26 января я вернулся в команду Контур.Бухгалтерии в роли менеджера разработки. 30 января Иван Ильин предложил мне зафиксировать цели на полгода-год. 01 февраля я отправил Ивану и Илье письмо, в котором оформил свои мысли. Цели и задачи из этого письма были полностью согласованы.

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

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

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

А вот и письмо:

---

Привет!

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

Тут есть два момента:

1. Я не до конца понимаю, как вы хотите использовать этот «артефакт»;
2. Я еще не полностью загрузился контекстом происходящего и возможно не вижу каких-то важных целей и задач.

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

Цель

Контур.Бухгалтерия должна вызывать восторг у своих пользователей.

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

Направления

По убыванию степени важности:

1. Dream Team. Идеальная команда делает идеальный продукт. Результат зависит от команды гораздо больше, чем от процессов, методологий, упоротого труда менеджеров и других фантиков. Поэтому развитие команды должно быть первым приоритетом. Сейчас я еще нахожусь в процессе первого знакомства с командой, поэтому пока вижу только такие поднаправления:
   1. Высокая мотивация
   2. Высокая ответственность
   3. Высокое качество
   4. Высокая продуктивность
   5. Эмпатия
   6. Комфортные коммуникация (как внутри команды, так и в межкомандном взаимодействии)
   7. Прозрачность работы
2. Качество. Качество сервиса – это базис в пирамиде пользовательских эмоций. Если сервис тормозит, ведет себя непредсказуемо или просто считает налоги с ошибками, то ни о каком восторге и речи идти не может. Соответственно, нужно обеспечить:
   1. Отсутствие багов, снижающих доверие к сервису
   2. Быстрый отклик сервиса на действия пользователя
   3. Предсказуемость поведения (если пользователь уверен, что сервис напомнит ему об уплате налогов, то мы не можем его подвести)
3. WOW. Эмоции – это то, что будет нас отличать от полчищ конкурентов. Мы будем самым интеллектуальным и заботливым сервисом.
   1. Большое количество интеллектуальных фишек, вроде фокуса, эксперта, распознавания.
   2. Большое количество фишек, которые будут показывать пользователю, что мы заботимся о нем.

TODO

Задачи, которые я собираюсь решить за следующие полгода, чтобы продвинуться в обозначенных направлениях:

1. Знакомство с командой. В результате этой задачи я должен понимать про каждого члена команды:
   1. Сильные стороны, способности
   2. Потенциальные сильные стороны
   3. Мотивация, что человеку нравится делать
   4. Текущие цели и планы
2. Организация регулярных встреч с каждым членом команды не реже раза в месяц (цель: раз в две недели). На этот график нужно выйти с марта.
3. Раз в неделю работать в паре с одним из разработчиков.
4. Раз в неделю работать дежурным программистом.
5. Внедрить в процесс элементы «нанотехнологий», методологии, которая бы позволила повысить WOW-эффект выпускаемых фич. Текущие претенденты: Design Thinking и Design for Delight.
   1. Пройти тренинг про внедрение Design Thinking в Scrum/Kanban (в марте в ScrumTrek);
   2. Написать Бланку из IntuitLab просьбу о помощи с D4D.
6. Понять причины проблем с качеством, тормозами и багами. Наметить на основе этого понимания дальнейшие шаги.
7. Организовать регулярную (ежедневную или еженедельную) доставку фидбека от пользователей команде.
8. Организовать оперативное уведомление команды о проблемах на боевой.
9. Внедрить в процесс практику, поощряющую инициативу и кооперацию.
10. Поднять планку качества выпускаемых фич: определить наше понимание необходимого качества и донести мысль до команды.
11. Организовать разработку интеллектуальных фич внутри команды: вернуть Даниила, придумать формат работы, который был бы всем интересен.
12. В БК должно начать развиваться направление DevOps: должен появиться человек, который отвечает за эту тему, с понятным планом дальнейших действий.
13. Повысить прозрачность работы:
    1. Регулярное (еженедельное) донесение актуальных планов и прогресса до маркетинга;
    2. Регулярное донесение актуального способа реализации до тех.поддержки (презентации релизов).

Это письмо носит информационный характер:) Обсуждать предлагаю лично.

Иван, если это необходимо, организуешь встречу для обсуждения/согласования?

—

Артем Зырянов