Русский
Русский
English
Статистика
Реклама

Управление проектами

Как стать тимлидом фронтендеров и как жить после этого расшифровка эфира

27.06.2020 14:19:52 | Автор: admin
15 июня в нашем инстаграм-аккаунте прошел прямой эфир с Ильей, руководителем фронтенд-разработки в Яндекс.Деньги. Выкладываем запись эфира и расшифровку.



Меня зовут Илья, я работаю в компании Яндекс.Деньги и руковожу фронтендом. До этого был бэкенд-разработчиком, писал на C#, около 5 лет назад перешел во фронтенд. Чуть больше года руковожу. Вот такой путь развития. Еще активно участвую в Burning Lead это сообщество для ведущих разработчиков, тимлидов, людей, которые так или иначе пересекаются с задачами управления; надеюсь, ребята из сообщества слушают стрим.


Про Node.js и его использование


Сначала скажу, как она у нас появилась и почему мы ею пользуемся. Исторически сложилось так, что у нас в Деньгах есть полноценный Java-бэкенд, в котором Java-разработчики работают с базами данных, с основной бизнес-логикой. Фронтендеры с бизнес-логикой не работают, мы подготавливаем для себя нужный формат данных и отправляем его на фронтенд, а там уже рисуем их на каком-либо фреймворке. Изначально у нас был Xscript-сервер, который ребята в Яндексе сделали еще в 2000-х годах это наше legacy. Часть логики серверный рендеринг мы писали на XML, XSL/XML преобразования. Так продолжалось очень долго. Потом, когда мы осознали, что разработчиков на XSL/XML стало тяжело искать, мы стали выбирать новый сервер, в который можно было бы писать на бэкенде и потом использовать на фронтенде. Оказалось, что есть целая платформа Node.js.

Тогда Node.js была очень молодой платформой, версия 0.10, наверно. Решено было использовать ее по нескольким причинам: язык Javascript набирал популярность, разработчиков было много; кроме того, серверную и клиентскую логику мог писать один разработчик без суперспецифичных знаний. О своем выборе мы не жалеем: платформа все еще активно развивается, оптимизируется, становится быстрее, получает полезные фичи, имеет активное сообщество.

Поговорим про архитектуру фронтенда и о том, чего мы хотели бы достичь в архитектуре Яндекс.Денег в целом. Так как мы используем Node.js, у нас уже долгое время основой серверного фреймворка служит Express. Он хорошо справляется со своей задачей обрабатывает запросы пользователя и дает ответы, больше от него ничего не нужно. Для него написано множество плагинов. Есть SSR для React-приложений, например; так как основной стек на клиенте это React, SSR не проблема прикрутить. Есть много реализаций; можно даже не писать код: разворачиваешь из NPM, он сам все делает.

Что касается архитектуры мы порядка 4-5 лет живем на Express, и из-за этого возникают некоторые проблемы. У нас довольно много разработчиков в отделе сейчас человек 50 и нам нужно писать понятный для всех код; разработчики могут менять интересы, переходить из команды в команду, и нам нужно, чтобы код был примерно одинаковым, чтобы разработчик в новой команде не тратил по месяцу на акклиматизацию к новому коду. Express довольно низкоуровневый фреймворк, и с ним живется довольно тяжело: каждая команда использует свое видение того, как писать обработчики запросов или бизнес-логику, ходить в бэкенд. Первая попытка наладить архитектуру сервера была совершена, когда мы сделали ProcessFlow. Я на эту тему выступал с докладами рассказывал, как на основе IDEF0 можно построить систему, которая позволит организовать бизнес-логику, задать правила ее написания, сделать поддержку, визуализацию связей между сущностями. Попытка была вполне успешной: в некоторых местах у нас были серьезные проблемы с пониманием кода, и ProcessFlow помогла их решить. Она работает и сейчас, и вполне нас устраивает.

Сейчас у нас идет переезд на NestJS. Это довольно современный серверный фреймворк, позволяет писать контроллеры в парадигме Model-View-Controller, организовывать бизнес-логику; его философия пришла из Angular. Его сильная сторона это правила, они уже на уровне фреймворка определяют написание контроллеров и бизнес-логики. Бесконтрольная среда бывает губительна, когда вас много и все пишут по-разному; лучше иметь свод правил, к которому всегда можно обратиться такой путь мы выбираем. Про NestJS активно рассказывает мой коллега Андрей Мелехов, ведущий подкаст devSchacht; он сейчас описывает процесс переезда на NestJS, обсуждает проблемы.

Мы стремимся к тому, чтобы перевести все приложения на NestJS. Еще мы продумываем более строгие архитектурные правила, чтобы сильнее снизить энтропию между разными приложениями в компании, и проводим дробление приложений по микросервисному подходу. Раньше у нас был монолит, и все было неплохо до того, как наша команда выросла и разработчики начали мешать друг другу по релизам, по функциональности и, кроме того, монолит долго собирался. Мы решили разделяться на микросервисы. Сейчас мы видим, что микросервисы во фронтенде это тяжело: на страничке нужно отобразить несколько доменных областей, при том, что каждый микросервис должен обслуживать только одну область. Мы видим, что микросервисы превращаются в мини-монолиты, и теперь мы смотрим в сторону микро-фронтенда, который позволит адекватно организовать фронтенд без пересечения предметных областей.

Про клиентскую часть


Она состоит из двух больших стеков. Первый это легаси-стек с использованием методологии BEM Naming (определенные названия CSS-стилей, позволяющие избегать пересечений), на основе которой в Яндексе создали фреймворк. Мы использовали его довольно долго, так как мы используем технологический стек Яндекса. Он классный, и в нем работа с компонентами организована примерно так же, как в современных фреймворках: в виде отдельно лежащих блоков, которые удобно поддерживать. Однако он уже устарел, поскольку основан на GQL и не отвечает современным требованиям по UI; на нем очень сложно делать анимации и приложения на клиенте. Мы постепенно переходим на React уже несколько лет (переход продвигается тогда, когда меняется дизайн или функциональность: то есть, все переписывания бизнес-процессов происходят на новой технологии). Он показался нам довольно мейнстримовым то есть, разработчиков на нем много. React основной фреймворк на клиенте, в качестве стейт-менеджера используется Redux; с ним же мы используем Redux-Thunk для асинхронных действий и запросов к бэкенду. В нескольких проектах использовали hooks.

Почему не Angular?


Когда мы выбирали стек, Angular был приблизительно версии 1.5. Он показался нам сомнительным, и мы выбрали другое решение. К последним версиям Angular я не имею претензий, но отказываться от React мы не хотим.

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


На самом деле, в каждой компании будут собственные требования к тимлиду или руководителю отдела, но, как мне кажется, есть и определенный план того, что нужно знать и делать, чтобы развиваться в направлении менеджмента. Есть такой подкаст PodlodkaPodcast, они публиковали такой план (роадмап). Крутая штука; там написано, что следует читать для развития нужных softskills на них нужно делать упор. Конечно, у хорошего тимлида должны быть и отличные hardskills: он не просто формальный лидер команды (допустим, 5 человек), он должен доказать свое лидерство, он должен учить свою команду, его люди должны желать научиться программировать так же, как может он. Но важны и softskill: коммуникативные навыки для общения в пределах команды и вне их, для отстаивания мнения команды, для поиска компромиссов. В работе тимлида очень много коммуникаций. Кроме того, нужно уметь проявлять эмпатию: при общении с разработчиками важно устанавливать понимание на уровне чувств, понимать настроение каждого собеседника, определять, чего он хочет. Напрямую это не говорится, но очень хорошо, когда тимлид владеет этим. Здорово, когда к hardskills также прилагается умение наставничества: за таким тимлидом потянутся люди, он будет в состоянии четко формулировать и ставить задачи.

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

Когда я стал тимлидом, проблемы только начались. Можно подумать, что на этом месте всё должно быть хорошо: разработчики работают, лид командует, и всё но это не так. Когда я был разработчиком, я делал понятную задачу и радовался своему достижению но у руководителя, как оказалось, задачи часто сильно размыты. Нужно улучшить что-нибудь. Например, надо ускорить время код-ревью: человек заходит, просматривает код и нажимает кнопку, что тут можно улучшать? Второй важный момент, который на тебя давит, состоит в том, что руководитель не решает прикладных задач своими руками. И тут происходит синдром самозванца: может казаться, что ты просто тратишь время, пока разработчики пишут код, и ты иногда чувствуешь себя бесполезным. Нужно понимать и знать свою ценность: коммуникации это тоже важная задача. Хороший руководитель помогает снять ненужные коммуникационные барьеры в ходе проекта; разработчики могут не коммуницировать, потому что им это некомфортно, но руководитель обязан.

Из плюсов можно назвать масштабность работы. Когда был разработчиком, я мыслил в рамках отдельного проекта. Проект мог быть большим, конечно, но в роли тимлида я мыслю в рамках всей компании: я должен сделать весь свой отдел лучше, чтобы вся компания стала лучше. От этого масштаба мне приятнее работать над проектами.

О процессах управления людьми в нашем отделе


Процесс разработки подразумевает общение разработчиков между собой, и у нас есть несколько точек пересечения. Задача на разработку поступает в одну из команд; обычно команда это Java-разработчики, фронтенд-разработчики, менеджер, продукт, обязательно тестировщики. Такая единица, сидит где-то отдельно. Существование других команд для нее особенного значения не имеет само по себе но нам необходимо, чтоб все команды писал приблизительно единообразный код. Для этого нужно общаться, и здесь есть несколько подходов. Во-первых, это происходящие время от времени встречи всего отдела; сейчас мы все собираемся в zoom, но это, конечно, не то. На встречах мы делимся новостями, ребята рассказывают, что они делают у себя в командах: какие у них проекты, какие будут в дальнейшем, что и как они делают. Это помогает строить представление о том, что происходит во фронтенде: он большой, просто так его рассмотреть не выйдет. Еще мы организуем tech talks, разные по масштабам: на всю компанию или на наш отдел, и там представляются технические приемы: например, на одном из них рассказывали, как используются hooks в React, как они влияют на форму, как выглядит код для них, какие плюсы и минусы. Такие доклады интересно слушать, и они помогают распространять по компании знания.Непосредственно в разработке есть процессы, которые позволяют нам общаться так, чтобы писать код, который потом не встретит непонимания на кодревью из-за используемых приемов, компонентов и библиотек то есть, мы стараемся нивелировать плохие последствия от изолированного принятия решений. Этот процесс, который мы называем Logic Review, позволяет нам узнавать мнения экспертов, ведущих разработчиков, старших разработчиков после того, как мы понимаем, как делать определенную задачу то есть, сверить наше видение реализации проекта с видением тех, кто определяет дальнейшее развитие всего отдела. Он позволяет нам обмениваться знаниями, технологиями, и контролировать однородность и архитектуру стека. Конечно, успеть везде и избежать всех проблем на кодревью невозможно, но такая сверка перед началом разработки позволяет уменьшить их количество.

Можно ли обмануть Review 360?


Напомню, что Review 360 это когда все (разработчики, тестировщики, менеджеры), с кем работал человек, которого нужно оценить, опрашиваются по кругу с помощью опросника. Я об этом процессе рассказывал на Burning Lead. Если команда небольшая, как у нас обычно человек 5-10 то этот процесс, собственно, не нужен: тимлид может сам пообщаться с каждым членом команды. Собственно, он и должен общаться с каждым разработчиком раз в 1-2 недели, чтобы понимать, чего хочет разработчик, какое у него настроение, доволен ли он задачами, как он работает, как проходит его рост. Но, когда команда большая например, у меня сейчас больше 50 фронтендеров то на такое личное общение уже не будет хватать времени. У тимлида есть и другие обязанности и проекты, он обязан развивать отдел, он не может тратить все рабочее время только на общение, которое впоследствии нужно будет еще и проанализировать. Поэтому приходится использовать менее точные подходы например, Review 360.

Можно ли его обмануть я думаю, имеется ввиду то, могут ли разработчики договориться между собой и поставить себе высокие оценки? Наверно, могут, но с менеджером и product owner так не договоришься: эти люди преследуют несколько другие интересы, и это будет легко вычислено. То есть можно, но ненадолго. Со временем станет понятно, что разработчик не делает свои задачи. Если product owner говорит, что разработчик не справляется, а другие разработчики ставят ему высшие оценки, то мы ясно понимаем, что существует проблема: либо product owner на него точит зуб, либо другие разработчики чего-то не замечают (или они договорились).

В целом, я думаю, что 360 Review довольно объективная вещь, и мы их проводим с определенным промежутком времени. Опыта по ним накопили еще не слишком много, но мы постепенно двигаемся вперед и совершенствуем методы подсчета статистики и наборы вопросов.

Расскажите про менеджер зависимости, composer и Laravel


Я знаю, что Laravel хороший PHP-фреймворк, и у нас на нем пишут, но сам с этими технологиями почти не работал.

У вас есть разделение на верстальщиков и JS-разработчиков, или разработчик делает все?


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

Что нужно знать джуниор-фронтенд-разработчику для работы в компании?


К сожалению, сейчас у нас нет открытых вакансий для джунов, но они бывают. Мы требуем знания теории языка Javascript. Это может показаться абсурдным, потому что теория JS в повседневных задачах вроде бы не нужна; однако мы знаем, что человек, изучивший теорию, умеет работать с информацией и воспринимать её. Кроме того, у него есть мотивация: он сел и разобрался с тем, как язык работает; когда он сталкивается с проблемой или сложным местом, он знает, как искать нужную для решения информацию (даже гуглить надо уметь).

Расскажите про архитектуру клиентской части. Есть ли у вас библиотека компонентов, и как она шарится? Сколько независимых приложений, все ли они в одном стеке?


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

Какой размер вашей команды?


У меня две роли в компании: я руковожу отделом порядка 50 человек и одновременно являюсь product owner нашей платформенной команды, там 8 человек.

React Native или Flutter?


У нас были эксперименты с React Native, Flutter тогда был очень новым; мы решили, что выберем React Native.

Яндекс хочет свой фрейм запускать?


Нет, BEM это очень старый фреймворк, он устарел, мы вместо него используем React. Никто не хочет запускать новый фреймворк.
Вопрос: на бэкенде только JS, или есть какие-то legacy-части?
Я рассказывал, что у нас есть сервер с Xscript с XML/XSL. Это как раз и есть наше legacy, мы его активно выпиливаем и хотим как можно скорее прекратить его использовать. В основном в 96% случаев у нас используется JS.

Redux-Thunk или Redux-Saga?


Мы использует Thunk. К Saga был подход; может быть, у нас тогда просто не было ребят, которые достаточно хорошо в ней разбираются, но преимуществ над Thunk мы не увидели. Сейчас уже есть подход с hooks, но пока Thunk очень активно используется.

Вы внутри компании или команды ставите задачи по Smart?


Когда мы делаем проекты, цели ставятся по Smart. То есть, мы должны четко представлять, что мы будем делать и к чему прийти. Новичкам тоже задачи ставятся по Smart. Но я не могу сказать, чтобы уже в процессе разработки всегда были четко прописанные задачи: часто, когда ребята в команде создают задачи, они могут быть совершенно по-разному описаны, но для новичков всегда всё описывается так, чтобы было ясно, как идти и к чему. То есть, не все 100% задач ставятся по Smart, но мы активно используем эту методологию.

Насчет микросервисов сейчас выкатили Module Federation Pack 5, можно ли в эту сторону посмотреть?


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

В чем разница в управлении 5, 10 и 50 людьми?


Во внимании, уделяемом разработчикам. Когда разработчиков 5-10, я могу с каждым из них пообщаться, выслушать проблемы, понять, чего они хотят и как развиваются. Когда их 50, это невозможно; конечно, это ухудшает ощущения от роли руководителя, потому что кажется, что я отделен от разработчиков, но сделать с этим ничего нельзя. Это основная разница. Кроме того, 5-10 человек это одна команда, которая вместе работает, но 50 человек не могут быть одной командой; такое количество разработчиков нужно разбивать по отдельным управляемым группам, иначе не получится держать фокус.

Будет ли массовый переход на NestJS?


Сложно сказать. Может, завтра появится новый фронтенд-фреймворк, превосходящий NestJS, и мы все будем на него переходить. Я думаю, что сейчас NestJS хорошо проработан, но нужно исходить из задачи. Для многих задач, которые мы решаем на Node, не нужен такой серьезный фреймворк например, для лямбда-функций, которые кто-то будет вызывать; но, когда на фронтенде есть развесистая логика, кажется, что подошел бы лучше Nest. Он сейчас хорошо проработан, есть и бэкенд-фреймворк (хотя он был довольно сырым, когда мы смотрели его). Nest развивается и, может быть, станет более популярным, но я не думаю, что будет массовый переход на него, как на Express.

Чем отличаются собеседования на джуна и миддла? Что оценивается во втором случае?


Когда мы собеседуем джуна, мы проверяем мотивацию человека, базовые знания JS, смотрим на коммуникативность и желание развиваться. С миддлом все интереснее: ведь миддлы это люди, которые пишут основную часть кода наших проектов; у них мало встреч, они большую часть времени именно разрабатывают. Мы должны хорошо проверить его hardskills (задачами), узнать, как он рассуждает, поговорить про архитектуру, спросить, как он организует проекты, рассмотреть его стиль написания кода. У самого миддла уже есть сформированные ожидания относительно компании то есть, с нашей стороны нужно донести, чего мы ждем от него и что можем предложить.

Есть ли какая-то боль в твоей команде, которую хотелось бы решить? С чем это связано, и какое может быть решение?


Мне бы хотелось сместить фокус на работу с людьми, чтобы в отделе уделялось больше внимания разработчикам. Мой фокус сейчас расплывается, потому что людей слишком много; моя задача как-то так выстроить общение (необязательно только с моим участием), чтобы проблемы, которые есть у ребят, и их желание развиваться не терялись, и доводились до логического завершения. Все нужно чинить и делать лучше. Может быть, можно сделать группы, в которых ребята, отвечающие за эти группы, будут общаться с разработчиками чаще, чем могу себе позволить я и решать их вопросы, либо эскалировать до меня, если нужно. Я думаю, так можно исправить потерю в коммуникациях: ведь, когда руководителю не хватает фокуса на разработчика даже из-за того, что разработчиков попросту много это влияет на его рост. Каждому разработчику нужно внимание так, как будто мы с ним сидим за соседними столами и работаем вместе. Я уже решаю эту проблему, но она не решена.

Как строите процесс по управлению таким количеством человек? Сколько лидов? Тяжело ставить цели?


Непросто. Очень много коммуникаций. Вместо официальных лидов у нас в каждой команде роль лидера выполняет самый опытный разработчик, который непосредственно работает и общается с людьми, проводит ревью, декомпозирует и нарезает задачи. С каждым таким лидом мы коммуницируем, пересекаемся на ревью. Есть еще более крупные направления (B2B, B2C), и у каждого направления есть человек, который за него отвечает. Он выстраивает работу в своем направлении, в том числе работу с людьми. Я стараюсь общаться как со старшими разработчиками, так и с ведущими разработчиками направления, как можно чаще; еще у нас есть общие встречи старших разработчиков, где мы обсуждаем новости, проблемы команд и процессов, думаем, что делать. Я думаю, старшие разработчики должны ощущать себя некоторой командой, с которой можно свернуть любые горы сделать процессы такими, как нужно, вместо того, чтобы смиряться с неудобствами.

Проводите 1 на 1? Как часто? Лайфхаки?


Собственно, у нас в компании ревью как раз называется 1 на 1. Сейчас я провожу со всеми старшими разработчиками ревью раз в месяц (это реже, чем рекомендуется лучше проводить раз в пару недель). Зачастую нам есть, что обсуждать. Лайфхаков особых нет в литературе достаточно подробно расписано про 1 на 1. Важно давать разработчику говорить он должен говорить примерно 80% времени; в этом суть: задача руководителя создать на ревью дружественную и безопасную атмосферу, чтобы разработчик мог ему рассказать все, что его беспокоит. Это довольно тяжело и не всегда получается, но круто, если 1 на 1 есть, и на них есть, что обсуждать. Их лучше проводить в неформальной обстановке например, можно в парке. Создание комфортной атмосферы может быть разным это не только переговорка в офисе.

Какие вакансии у вас открыты?


В каком направлении? У нас довольно много в разных направлениях. По фронтенду мы ищем нескольких миддл-разработчиков (по-моему, 2), можно и senior.

Какие сложные задачи возникают у руководителя?


Сложно говорить о сложности задач, когда ты их решаешь. Допустим, отказ от легаси это сложная задача. Есть бизнес, который хочет развиваться; есть ты, руководитель, который хочет, чтобы легаси не стало. Нужно находить общий язык с бизнесом и добиваться внесения в бизнес-план задач по отказу от легаси, что нетривиально. Это требует хороших коммуникативных навыков, хорошего фокуса нужно постоянно держать на пульсе руку; задача бизнеса зарабатывать деньги, он не любит отказываться от работающих легаси-систем.
Сложная задача придумывать задачи по улучшению работы в отделе. Нужно анализировать, с какими проблемами сталкиваются разработчики, не забывать улучшать dev-experience. Выявлять проблемы это тоже нетривиально.

Рассматриваете фронтов на удаленке?


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

Что делать, если тимлид слабоват и явно не должен оставаться на позиции?


Нужно использовать механизм подачи обратной связи. Это мощный и классный механизм, но, конечно, нужно делать это аккуратно, чтобы человек не обиделся. Нужно уметь проявлять эмпатию, понимать чувства человека, давать в правильном направлении обратную связь. Он может либо принять, либо не принять ее; если он стал тимлидом, он должен уметь работать над собой и принимать обратную связь. Важно не просто дуться на него из-за того, что он не дотягивает, а сказать ему конструктивно, что, на ваш взгляд, делается плохо, и узнать его мнение. Я сам не мастер подачи обратной связи, мне еще предстоит этому научиться, но я знаю главное правило: говорить про действие, а не про личность. Если рассказать лиду, какие вещи в команде проседают может быть, все починится.



А что дальше?


30 июня в 20:00 в нашем инстаграм-аккаунте будет выступать Влада Рау Senior Digital Analyst в лондонском офисе McKinsey Digital Labs. Сейчас Влада занимается product/data engineering. До своего переезда в Лондон она дважды стажировалась в Google в Дублине, а также училась в ВШМ СПбГУ и IE Business School в Мадриде.

Задать ей вопрос можно в комментариях к этому посту.



Что было ранее


  1. Илона Папава, Senior Software Engineer в Facebook как попасть на стажировку, получить оффер и все о работе в компании
  2. Борис Янгель, ML-инженер Яндекса как не пополнить ряды стремных специалистов, если ты Data Scientist
  3. Александр Калошин, СEO LastBackend как запустить стартап, выйти на рынок Китая и получить 15 млн инвестиций.
  4. Наталья Теплухина, Vue.js core team member, GoogleDevExpret как пройти собеседование в GitLab, попасть в команду разработчиков Vue и стать Staff-engineer.
  5. Ашот Оганесян, технический директор и основатель DeviceLock кто ворует и зарабатывает на ваших персональных данных.



Подробнее..

3 простых инструмента тайм-менеджмента для удалёнки и неудалёнки

25.06.2020 18:18:39 | Автор: admin

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


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



Сейчас основная сложность в том, что поток информации увеличился в несколько раз. Мы уже давно живём в цифровом мире. А в эпоху самоизоляции почти 100% людей заметили, что стали работать ещё больше.


Потоки информации стали еще объёмнее, количество информации стало еще больше, от компьютера мы не отходим примерно с утра до вечера, а вечером "пересаживаемся" на смартфон.


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


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


Инструмент 1. Есть такая очень известная матрица она называется Матрица Эйзенхауэра. Да, она у всех уже набила оскомину, как buzzword. Но, в целом, многие люди не знают, что можно достаточно быстро фильтровать входящую тебе информацию, как важную и срочную. И, соответственно, это матрица 2 на 2: срочные важные, срочные неважные, не срочные важные, не срочные не важные.


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


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


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


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


Если правильно работать над не срочными, но важными задачами, срочных и важных задач просто не появится.


В идеале такого, наверное, не бывает никогда.


Но, тем не менее, можно свести к нулю. Есть отдельный вид задач, который не срочные, но важные. Важные, но не срочные это те, которые можно и нужно делегировать. Это те задачи, которые нужно трактовать очень широко. То есть, делегировать не просто подчинённым дать. Допустим, чтобы убирать дома имеет смысл начать нанимать людей, которые убирают, а ты в это время продуктивно потратишь на какой-то свой продукт. Или не ходить в магазин, а заказать доставку. В современном мире возможностей для делегирования очень-очень много.


Инструмент 2. Он называется пустой Inbox. Это те задачи, которые важные, которые сыпятся тебе, которые нужно сделать здесь и сейчас. Есть такая рекомендация, Inbox это хранилище всей входящей к тебе информации. Его нужно держать пустым, свободным, проработанным. Это просто психологически приятно да и полезно иметь его пустым. Когда ты задачу, либо делаешь, либо планируешь на выполнение, получаешь такую галочку в голове, дофаминово-окситоциновую дозу, что ты сделал, молодец. Ты сделал это правильно, завершение принято, задача сделана, и мозг тебя за эту дофаминовую мотивационную конфетку и получает.
Эта конфетка та же, что за листанием в Фейсбуке, но здесь ты реально за дело получаешь и продвигаешься вперёд по своей жизни, а не бездумно пролистываешь километры чужих бесполезных тебе жизней. Поэтому, держать его, по возможности, надо пустым, руководствуясь третьим правилом.


Инструмент 3. Называется правилом 5 минут. То есть, на любую задачу, которая попадает в твой Inbox, у тебя есть 5 минут. Почему 5 минут? Потому что, как правило, ты какой-то задачей занимаешься, и ты можешь отвлечься от неё не больше, чем на 5 минут. Почему на 5 минут? Потому что за это время у тебя не успеет уйти контекст предыдущих задач, и ты успеешь к ним вернуться, не потеряв наработки.


В течение 5 минут что можно сделать? Если задача занимает меньше 5 минут, ты сразу её делаешь. Маленькую задачу за 5 минут нужно делать сразу и всегда. Потому что это заблуждение, что, если я сейчас ее не сделаю и отложу на потом, мол, как будто на балкон вынесу и у тебя вдруг придёт в выходные озарение убрать там всё, что у тебя накопилось на балконе, вы не уберёте там никогда. А, если бы, грубо говоря, какая-то картонная коробка осталась, выкинь пойди лучше сразу, не перекладывай на балкон, чтобы потом думать, что с ней делать. Она всё равно будет торчать в памяти, как лом в голове и дверные косяки будет задевать и бейсболка сидеть будет криво.


Второй момент, если задача за 5 минут не укладывается, такое реально бывает, что мы можем сделать? Мы можем запланировать её выполнение, примерно прикинуть, когда к ней можно прийти. То есть, таким образом все задачи, которые у тебя в Inbox поступают, ты их маркируешь, например, планируешь для выполнения, либо выполняешь. Таким образом, у тебя все задачи в твоем Inbox должны быть пустыми.


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


Советами по тайм-менджменту в эпоху пандемии поделился Алексей Куксёнок, соавтор и ведущий онлайн-курса Профессия SCRUM-мастер. Первый бесплатный семинар курса пройдёт 9 июля в 19-00. Алексей проработал 15 лет в ИТ-индустрии в различных ролях, 12 из которых в иностранных компаниях, как продуктовых, так и сервисных. За время карьеры побывал и на стороне исполнителя, и на стороне заказчика. Руководитель проектов в компании DataArt, входящей в Inc. 500 I 5000 (самые быстрорастущие компании США), в список 1000 компаний вдохновляющих Британию. Участвовал в трех десятках проектов с численностью сотрудников от 2 до 60 человек, реализованных, как и с использованием гибких методологий (Scrum, Kanban), так предиктивных (PMI-PmBoK). Спикер международных и российских конференций, организатор митапов, воркшопов, конференций и тренингов.

Подробнее..

Точка кристаллизации негатива в команде Как ее найти и что с ней делать?

01.07.2020 08:11:29 | Автор: admin

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


В чем тут основная сложность? Если быть точным, то сложностей тут две:
1) такая ситуация действительно может только казаться;
2) если не кажется, что с этим делать?


Давайте разбираться. Я лично сторонник нескольких подходов в решении таких задач.



Красота в глазах смотрящего


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


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


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


Конечно, такие метрики в отношении людей не дают 100-процентной гарантии, потому что людей сложно оцифровать, но это лучше, чем ничего.


Мы живем в матрице


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


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


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


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


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


Это первая метрика, которую следует проверить, прежде, чем приступать к изменениям.


Отделяем зерна от плевел


Второй подход состоит в том, чтобы определить, а в чем же собственно проблема и есть ли она вообще? Даже, если вы заметили какое-то нарастание негатива в команде, и решили, что проблема действительно имеет место, то нет. Рано. Пока это не проблема, а факт.


Условно говоря, то, что солнце встает каждое утро это факт. Вода в море мокрая. Снег холодный. Грязь пачкает одежду. Это всё факты.


Для кого-то это проблемы, для кого-то нет. Если человек отпускает язвительные комментарии в адрес кого-то или чего-то вокруг происходящего, это факт. Вопрос, это проблема или нет? И если да, то в чём она состоит? Проблема для команды, проблема для производственного процесса или ещё для чего-то?


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


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


Если уровень Лосада в вашей команде показывает плохую погоду, то задача определить проблема это или нет. То есть, на кого влияет сложившаяся ситуация, как влияет, что будет, если ничего не менять? В 90% случаев оказывается, что никакой проблемы нет или она в другом месте. Проблема не в том, что сотрудники сидят в соцсетях, а в том, что работа не делается, но с соцсетями это может быть не связано аж никак.


Поэтому прежде чем решить проблему, убедитесь, что проблема есть, потом уже решайте ее.


Чемоданчик лидера


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


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


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


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


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


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


Советами по работе с командой поделился Алексей Куксёнок, соавтор и ведущий онлайн-курса Профессия SCRUM-мастер. Первый бесплатный семинар курса пройдёт 9 июля в 19-00.


Руководитель проектов в компании DataArt, входящей в Inc. 500 I 5000 (самые быстрорастущие компании США), в список 1000 компаний вдохновляющих Британию. Участвовал в трех десятках проектов с численностью сотрудников от 2 до 60 человек, реализованных, как и с использованием гибких методологий (Scrum, Kanban), так предиктивных (PMI-PmBoK).

Подробнее..

Сколько стоит сделать ролик об игре своими силами

29.06.2020 16:21:22 | Автор: admin


Предположим, у вас есть игра и команда, которая её разрабатывает. Вам нужен ролик о своей игре и вы пока не решили, делать его своими силами или отдать на аутсорс. Давайте посмотрим, как может сложиться ситуация, если вы выберете первое: создать ролик самостоятельно.

Из этой статьи вы узнаете, расходы какого порядка могут скрываться за решением самостоятельно сделать видеоролик о своей игре. Предупреждаем: это лонгрид с зубодробительными подробностями видеопроизводства. Поехали?

Написано в Alconost

При подготовке этого материала мы опирались на собственный опыт создания роликов об играх: мы сделали их больше сотни за последние 8 лет. А чтобы перевести времязатраты в деньги, мы воспользовались результатами исследования InGame Job по зарплатам в геймдеве. С опорой на опыт и знания мы попробуем посчитать, в какую сумму среднестатистической геймдев-студии может обойтись создание ролика об игре собственными силами.

Ролики об играх бывают очень разные. Иногда это нарезка видеозахватов, а иногда анимация персонажей или 3D-моделей или даже мультипликация. Безусловно, разная сложность это и разные трудозатраты, поэтому ролики об играх могут в разы отличаться друг от друга по стоимости. Звучит логично, но уж слишком абстрактно, правда?

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

Начнём с трёх допущений: какой именно ролик вам нужен, какими именно сотрудниками вы располагаете и как именно вы выстроите процесс производства видео.

  • Ролик: допустим, вам нужен ролик-трейлер, длительностью не больше минуты, для размещения на сайте игры и в Google Play. Пусть ролик будет на английском, с озвучкой диктором-носителем английского языка, с музыкой и звуковыми эффектами.
  • Команда: предположим, что в команде есть ребята, у которых достаточно знаний, навыков и квалификации, чтобы написать сценарий, создать графику для ролика и анимировать её, а также сделать звуковое оформление видео. Также предположим, что в команде полное взаимопонимание, и каждый в команде может выделять на эту задачу половину рабочего дня без ущерба прочим обязанностям.
  • Процесс: возможно, вы решите следовать процессу создания роликов в Alconost: написать сценарий, сделать раскадровку, записать озвучку, подобрать фоновый трек, собрать анимацию, смонтировать музыку, добавить звуковые эффекты. Не исключено, что в вашем случае процесс нужно подтюнинговать, но как именно можно судить, только зная особенности конкретной игры и конкретной команды. Раз сама ситуация, ролик и команда у нас условные, пусть хотя бы процесс будет конкретный и универсальный.

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


Фото: StartupStockPhotos, Pixabay

Сценарий


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

Чтобы художник, аниматор и диктор точно поняли, что им нужно делать, сценарий должен отвечать на такие вопросы:

  • В каком визуальном контексте будет происходить всё действие? Это простой градиент, плоский детализированный арт или 3D-окружение? С этим нужно разобраться в самом начале, чтобы все решения по визуальной части были консистентными. Добавляйте в сценарий референсы.
  • В каком порядке в ролике будут показаны главные фичи игры и каким именно образом? Если некоторые фичи выглядят недостаточно фотогенично (мешают кнопки, много текста, мелкие иконки), в сценарии нужно предусмотреть, как именно такие фичи будут демонстрироваться.
  • Каким будет закадровый текст? Диктор озвучивает предоставленные ему фразы, не внося корректировок на свой вкус, так что сценаристу нужно убедиться, что текст озвучки ёмкий, точный и складный.


Фото: Free-Photos, Pixabay

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

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

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

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

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

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

Раскадровка


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


Фото: VitalikRadko, Depositphotos

Первым делом художник проникается сценарием, смотрит референсы и подбирает арт из уже отрисованных ассетов (находит графические исходники персонажей и, конечно, наручей испуганной нимфы в архиве игровой графики). Затем разрабатывает визуальный стиль: готовит фон, рисует плашки, подбирает шрифт. Так как по сценарию предусмотрено кадрирование видеозахватов, художнику нужно подумать, как компенсировать разницу пропорций между соотношением сторон кадрированного видео (может получиться, например, 1:1) и высотой и шириной кадра (обычно 16:9).

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

Предположим, что в нашем случае художник уделяет раскадровке по 4 часа в день и справляется за неделю, включая один-два цикла правок. В этом случае его времязатраты составят около 20 часов.

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

Анимация


Аниматор знакомится со сценарием, смотрит референсы и анимирует раскадровку, подготовленную художником. Также аниматор монтирует видеозахваты: менеджер проекта (о нём далее) их уже отснял и предоставил аниматору вместе с таймкодами удачных фрагментов и инструкциями по их кадрированию и улучшению.


Фото: sonerbakir, Depositphotos

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

Предположим, что анимация графики займет 30 часов, а работа с захватами 10. Допустим, полная черновая сборка в целом понравится команде, но без улучшений не обойтись. Пропустим черновик анимации через три цикла правок (пусть они займут 4, 3 и 2 часа: чем ближе к финальной версии, тем меньше корректировок) и дадим аниматору ещё часок на шлифовку финальной версии. При таком ходе работ трудозатраты аниматора составят 50 часов.

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

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

Звукорежиссура


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

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

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


Фото: princeoflove, Depositphotos

Будем считать, что на монтаж музыки, подбор звуковых эффектов и сведение у звукорежиссёра уйдет около 4 часов, и ещё час понадобится на внесение правок после согласования с командой (бдыщь не подошел надо буммм, и тому подобное). Итого 5 часов.

Остаётся только попросить аниматора свести финальное видео с финальной аудиодорожкой и ролик готов.

Менеджмент


Менеджер делает всё, чтобы процесс работы над роликом шёл продуктивно и был команде в кайф. Иначе зачем это всё?

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


Фото: ilixe48, Depositphotos

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

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

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

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

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

Суммируем время


Давайте подсчитаем, сколько приблизительно времени ушло на создание ролика в нашем случае.

  • Сценарий: 10 ч.
  • Раскадровка 20 ч.
  • Анимация: 50 ч.
  • Звукорежиссура: 5 ч.
  • Менеджмент: 30 ч.

Итого: 115 часов.

Условной геймдев-команде понадобилось около 115 часов, чтобы сделать условный видеоролик о своей игре. Безусловно, наши воображаемые ребята могли где-то справиться быстрее, а где-то залипнуть надолго. Может быть, команда поторопилась со сценарием и при создании раскадровки выяснилось, что не всё получается показать так, как задумано? Или при сборке анимации оказалось, что в сценарии не упомянули что-то важное, и пришлось вернуться на пару шагов назад? А может, ребятам удалось подключить разработчиков к созданию ролика, снять с движка идеальный геймплей и времязатраты на сборку анимации и монтаж захватов удалось сократить?

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

Реальные времязатраты на создание конкретного видеоролика об игре могут быть как 20 часов, так и 200. Точному расчету, который было бы справедливым для любого ролика о любой игре, мешают нюансы. А их десятки: от специфики конкретной игры и её фотогеничности до нюансов разработки, технических и организационных, которые в каждом случае уникальные.

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

Переводим в деньги


Сделать своими силами это не значит сделать бесплатно. Ролик делают сотрудники компании, они получают зарплату, а значит каждый час их времени стоит денег.

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

Для этого воспользуемся исследованием компании InGame Job, которая в 2019 году опросила 2000 сотрудников геймдев-компаний из России, Беларуси и Украины и высчитала медианную зарплату специалистов на разных должностях.

Роли, которые сотрудники геймдев-студии исполняют в нашем условном проекте, мы соотнесём с должностями, упомянутыми в исследовании. Чтобы выяснить, сколько стоит один час работы каждого специалиста, разделим медианное значение зарплаты за месяц на 21 рабочий день, а полученное число разделим на количество часов в рабочем дне 8.
Роль в проекте / Должность в списке InGame Job Медианная зарплата, $ Стоимость 1 рабочего часа, $ Затрачено времени на ролик, ч. Стоимость часов, затраченных на ролик, $
Копирайтер / Narration Designer 1100 6,5 10 65
Художник / 2D Artist 950 5,6 20 113
Аниматор / Animator 1420 8,5 50 423
Звукорежисcёр / Sound Engineer 1200 7,1 5 36
Менеджер проекта / Project Manager 1800 10,7 30 321
Итого 958

Выходит, что время, затраченное условной командой на создание условного ролика, эквивалентно приблизительно 960 долларам. Это без учёта времязатрат, которые понадобились команде на переговоры друг с другом при обсуждении промежуточных результатов. Оставим это время за скобками: разброс времязатрат здесь практически непредсказуемый, вплоть до отличий на порядок, а количество допущений в расчётах уже приближается к критическому.

Но есть кое-что ещё, что поддается относительно точной калькуляции, а мы это пока не отразили в расчётах.

Прочие расходы



Фото: Arek Socha, Pixabay

  1. Перевод: $20. Столько стоит перевод 1000 знаков с русского на английский в исполнении английского носителя языка в сервисе профессиональных переводов Nitro. 1000 знаков это как раз 120 слов озвучки (идеально для минутного видео) и 8 коротких слоганов.
  2. Дикторская озвучка: $100. Цены на озвучку зависят и от объема текста, и от конкретного исполнителя и его условий, в том числе от минимальной стоимости заказа. Предположим, что мы выбрали опытного диктора из США, который записывается в профессиональной студии и в списке услуг которого есть как раз то, что нам нужно: озвучка роликов для Интернета, длительность до 1 минуты за фиксированную ставку.
  3. Стоковый трек: $30. Бывают треки и по $15, и по $50, а ещё цена в разы увеличивается, если нужна лицензия расширенного типа например для использования в ролике, который будет размещаться на ТВ. Допустим, мы выбрали не самый дорогой трек по стандартной лицензии, которая как раз подходит для публикации ролика на Youtube.

Прибавим эти затраты ($150) к ранее вычисленной сумме. $960+150 = $1110.

Выводы


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

Заказать ролик на аутсорсе или всё же сделать самостоятельно? Каждая геймдев-команда решает на своё усмотрение.

Если вы решите аутсорсить видео посмотрите, какие ролики об играх делают в Alconost.

А если решите делать сами не забудьте надеть наручи испуганной нимфы или другой артефакт, приносящий удачу.

Об авторе


Статья написана в Alconost. Мы уже 8 лет создаём рекламные и обучающие видео, в том числе трейлеры, тизеры и прероллы для игр и приложений. А ещё мы занимаемся локализацией приложений, игр и сервисов на 80+ языков.

Подробнее: alconost.com. Подпишитесь на нас ВКонтакте, Фейсбуке или Твиттере, чтобы первыми увидеть наши свежие работы и анонсы новых публикаций.

Другие наши статьи о создании видеороликов


Подробнее..

Как выбрать нишу для создания своего курса или онлайн школы?

30.06.2020 16:15:52 | Автор: admin
Карантин создал условия, в которых все проекты вынужденно перешли в онлайн формат. Те, кто ранее старался оттянуть процесс диджитализации своего бизнеса, столкнулись с экстренной необходимостью делать все на вчера. Больше месяца изоляции перекроило рынок, и многие пока еще не успели осознать, насколько сильно влияние карантина отразилось на мировой экономике.

На пике подъема оказались те виды предпринимательства, которые легко работают и управляются в удаленном режиме. На пике роста оказалась ниша онлайн образования. У людей освободилось время для потребления контента и самое главное сформировалась привычка учиться онлайн. Что теперь со всем этим делать?

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



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

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

Если вы собираетесь стартовать самостоятельно, и настраивать все процессы, от создания продукта до продвижения и монетизации самостоятельно, то на протяжении первых 3 месяцев будете зарабатывать на уровне 1-3 тыс. дол. Это при условии, если у вас действительно хороший продукт с ярко выраженной целевой аудиторией и вы даете решение проблемы своему клиенту.

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

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

Как выбрать нишу для запуска своего проекта?


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

Способ 1 Отталкиваясь от личной экспертности


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

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


Способ 2 Выбрать трендовые направления


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

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

Способ 3 Найти эксперта и продюсировать его


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

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

Я не понимаю, что хочу. Как пользователю сформулировать требования к CRM

07.07.2020 14:13:48 | Автор: admin
Когда кто-то трогает крестик, должен плакать персиковый медвежонок*, это, пожалуй, самое милое требование из тех, что мне приходилось встречать (но, к счастью, не реализовывать). Оно было сформулировано сотрудницей с 12 годами опыта работы в одной компании. Вы поняли, что ей нужно (ответ в конце)? Уверенное второе место занимает это: Биллинг должен запускаться по моему желанию, желание выражается на мобильнике**.

Действительно, далёкие от IT пользователи зачастую не могут сформулировать свои требования и ведут себя с разработчиками довольно странно. Поэтому мы решили написать доступную для всех статью: простым пользователям и неайтишному бизнесу она поможет легко сформулировать требования, ну а нам, айтишникам, тема на обсудить и поделиться опытом.


Пользователь избегает ответственности за требования


Если посмотреть те запросы, которые люди пишут о CRM в социальных сетях или в профильных сообществах, есть чему удивиться. Множество возмущённых постов о том, что нельзя найти CRM для длинных продаж, дистрибуции машинного масла, агентства наружной рекламы и т.д. И если человек занимается оптовыми продажами сена, то они ищут именно CRM Seno version и никак иначе. А вот в процессе общения с вендором такие запросы как-то сразу отпадают, потому что человек, выбирающий CRM, погружается в тему и понимает, что современные CRM-системы способны решить задачи практически любого бизнеса дело не в отраслевой версии, а в настройках и индивидуальных доработках.

Так откуда возникают неадекватные требования?

  • Главная причина непонимание сущности CRM-системы как технологии. Любая современная CRM-система в своей основе имеет множество разных таблиц, которые между собой связаны ключевыми полями с определёнными значениями (кто не знаком с СУБД, но когда-то работал с MS Access, легко вспомнит эту визуализацию). Поверх этих таблиц строится интерфейс: десктопный или в вебе, без разницы. Работая с интерфейсом, вы фактически работаете с теми самыми таблицами. Как правило, задачи абсолютно любого бизнеса можно решить с помощью настройки интерфейса, создания новых объектов и новых связей в совокупности с одновременным обеспечением логики их взаимодействия. (доработка).

    Да, бывает, что сфера деятельности компании требует какие-то особенные решения: медицина, строительство, недвижимость, инженерное дело. Для них существуют свои профильные решения (например, RegionSoft CRM Media для телерадиохолдингов и операторов наружной рекламы там особенным образом реализованы и медиапланирование, и работа с монтажными листами и эфирными справками, и управление местами размещения рекламы).

    Но в целом компании малого бизнеса могут использовать CRM-систему даже без доработок и покрывать все нужды оперативной работы. Именно потому что CRM создаётся как универсальное решение для автоматизации бизнеса. А то, насколько она будет эффективна для вашей компании, зависит от того, как она будет настроена и наполнена данными (например, в RegionSoft CRM есть несколько классных инструментов, которые можно адаптировать точно под нужды конкретного бизнеса и даже его отделов: редактор бизнес-процессов, настраиваемый калькулятор для построения расчётов параметров продукции, механизм для настройки сложных KPI и это подходящие механизмы для любой компании).
  • Представитель бизнеса о CRM знает от других, мнение основано на чужом негативном опыте. Он полагает, что и с ним случится что-то подобное, не подозревая, что его знакомый никогда не скажет я не разобрался в CRM или я зажал деньги на внедрение и обучение, а теперь страдаю, нет, он обвинит разработчика или вендора втюхали мне эту CRM, продали и в кусты и т.д. Такие ребята нередко решают, что вендор должен тратить часы времени сотрудников совершенно бесплатно (не могу понять, почему они же не требуют бесплатного обслуживания и ежедневной мойки автомобиля от завода-изготовителя или дилера, а спокойно оплачивают стоимость ТО официального дилера.
  • Потенциальные клиенты считают, что раз на рынке есть кто-то, кто предлагает CRM бесплатно (с кучей ограничений и звёздочек), то и остальные должны просто раздавать CRM-системы. Бесплатные CRM в Яндексе ищут около 4000 человек ежемесячно. На что они надеются непонятно, ведь по сути любая бесплатная CRM, если она рассчитана более чем на одного человека, всего лишь урезанная демо-версия и маркетинговый инструмент.

Есть и другие причины, но эти три идут с большим отрывом. С такими клиентами работать довольно непросто, поскольку у них уже есть сформированный образ идеальной по их мнению CRM и они нередко ждут ответа на свой вопрос типа: Нет, вы мне дадите CRM для продаж холодильного торгового оборудования марки Север или мне звонить в Германию и заказывать SAP?. При этом бюджета на внедрение CRM хватит разве что на звонок в эту самую Германию. Звучит немного зло, но на самом деле идти с ультиматумом к разработчикам CRM гораздо менее продуктивно, чем обсуждать требования и прислушиваться к опытным внедренцам.

Как формулировать требования?


Функциональные требования


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

  1. Повышение эффективности работы. Если команда продаж в первую очередь и вся компания в целом увязла в администрировании, упускает важные события и теряет клиентов, забывает выполнить задачи в срок, то необходима помощь программы в управлении временем и задачами. А это значит, что среди ваших первых требований должны быть классная карточка клиента, разнообразные планировщики и возможность быстро собирать информацию по клиентам в единой базе. Довольно стандартные требования. На этом этапе можно предъявить дополнительное требование автоматизацию бизнес-процессов, которая упорядочивает рутину в бизнесе любого размера.
  2. Повышение объёма продаж. Если вам нужно больше продаж, особенно в кризис, который тут кружит над нашими уже седыми от нервов головами, то у вас есть ключевые подзадачи: сбор полной информации о клиенте, сегментация и персонализация обращений к клиентам, быстрая работа с оформлением сделки и информативная воронка продаж. Это всё тоже есть в стандартных CRM-системах.
  3. Отслеживание эффективности работников (не путать с контролем времени сотрудников, мы на этом поле не играем!). Вот здесь всё уже интереснее. Найти CRM, которая решит две предыдущие задачи, очень просто, найти CRM с KPI сильно сложнее, найти CRM с настоящим, многокритериальным, аналитическим механизмом KPI совсем непросто (если ищете, то у нас есть RegionSoft CRM Professional 7.0 и выше, а в ней KPI). Если в выбранной вами CRM-системе нет системы KPI, вы можете попросить такую доработку, однако она скорее всего будет довольно дорогой, потому что это практически отдельный модуль для любого ПО.
  4. Безопасность. На первый взгляд, CRM не относится к инструментам обеспечения корпоративной безопасности. Но автоматизация без управления безопасностью выглядит несостоятельно. Нередко к выбору CRM приводит желание руководителя избавиться от серых схем, откатов и своих персональных клиентов у продажников. CRM-система хранит данные, сохраняет клиентскую базу от попыток копирования и передачи третьим лицам, благодаря разделению прав доступа помогает контролировать круг клиентов и компетенций каждого сотрудника. И заметьте вы контролируете и делаете безопасной непосредственно рабочую деятельность, а не время сотрудников на работе.

Как правило, требования формулируются не по одной из перечисленных задач, а по нескольким. Это справедливо: раз современная CRM давно стала CRM++, почему бы не использовать её возможности не только для отдела продаж, но и для всей компании сразу. Например, календарём, телефонией, планировщиками, записями о клиентах и бизнес-процессами могут пользоваться все сотрудники компании. Как итог вся команда собрана в одном интерфейсе. Оптимальный путь, особенно сейчас, в условиях удалённой и частично удалённой работы.

Перечисляя те функции, которые вам необходимы и примеряя их к реальным процессам в компании, вы формулируете функциональные требования к CRM. Ими дело не ограничивается.

Дополнительные требования к CRM


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

Как оценивать стоимость CRM?


У нас была большая статья о том, сколько стоит CRM, но там изложен универсальный подход, который можно применить и для ИП на 3 человек, и для оператора связи на 1500 сотрудников. Для малого бизнеса ситуация выглядит несколько иначе и тем более мы призываем вас посмотреть на неё иначе в условиях нынешнего кризиса.

Итак, вам нужна CRM и у вас в компании 10 сотрудников, каждого из которых вы хотите подключить к единому информационному ресурсу компании пусть к RegionSoft CRM Professional (мы не имеет права рассматривать чужие решения).

Если вы решите купить CRM, то заплатите за все лицензии один раз 134 700 рублей (по состоянию на июль 2020 года). Это, с одной стороны, оптимальный путь: заплатил и забыл, эти 134.7 тыс. не прирастут ни через год, ни через три. Если вы, например, арендуете облачную CRM, то в первый месяц вы заплатите всего 9000 рублей, но через год это будет уже 108 000, через два 216 000, через три 324 000 (и то, если обойдётся без ежегодной индексации цен).

Но! Мы знаем, что у бизнеса сейчас может не быть 134 700, а CRM в кризис нужна больше чем когда-либо. Поэтому у нас есть рассрочка 26 940 в месяц и аренда 11 233 в месяц с правом выкупа. При этом вы получаете не какой-то уменьшенный пакет функций, а всё ту же мощную редакцию.

Мы сделали эту выкладку далеко не только ради рекламы. Если вы приходите к вендору, стоит правильно формулировать ценовые требования.

  • Не просите бесплатную версию вы по факту продадите её сами себе (потому что это бесплатно) и попадёте на маркетинговый крючок: в итоге всё равно купите, но вас немного задолбают общением, а вы потом задолбаетесь из-за ограничений функциональности.
  • Если вы не готовы оплатить год аренды или всю стоимость решения on-premise, обсуждайте возможность рассрочки и дискретных платежей.
  • Никогда не заказывайте доработку сразу, если вы не уверены, что функция понадобится прямо сейчас и её нет в CRM. Лучше начните использовать CRM-систему и постепенно сформулируйте, что вам необходимо доработать и как эта доработка будет использоваться в компании.
  • Уточните у вендора, какие дополнительные затраты обязательны: у кого-то это платный внешний почтовый клиент, обязательное подключение к единственному оператору IP-телефонии, пакет технической поддержки и проч. Эти затраты могут стать внезапным и неприятным сюрпризом.
  • Узнайте стоимость внедрения и обучения в 90% случаев это оправданные расходы, которые окупаются благодаря быстрому и правильному старту работы в CRM-системе.

И помните: деньги не должны быть единственным требованием! Если вы будете ориентироваться только на стоимость программы, то скорее всего просто не сможете выбрать то решение, которое нужно бизнесу.

Итак, мы с вами разобрались с двумя самыми важными требованиями: функциональностью CRM-системы и с деньгами, которые предстоит за неё заплатить.

Какие ещё требования могут быть к CRM?


  • Нагрузка на CRM-систему. Расскажите вендору, какое количество информации планируется ежедневно вносить в базу, как она должна храниться и какие резервные копии иметь. Для большинства современных CRM это по-прежнему принципиальный момент, который может сказаться на скорости работы, стоимости, модели поставки и т.д.
  • Возможные настройки. Обговорите заранее, какие настройки для вас особенно важны. Это может быть воронка продаж, почтовый клиент, рассылки, обязательно распределение прав доступа и т.д. Как правило, тут пожелания бывают самые специфические.
  • Совместимость с существующей инфраструктурой. Уточните, какие интеграции возможны, как организована телефония, какое серверное оборудование требуется и требуется ли (для десктопных CRM-систем). Посмотрите, с каким ПО из вашего зоопарка пересекается CRM и откажитесь от него для экономии и наведения порядка в делах.
  • Безопасность. Если у вас есть особые требования к безопасности, обговорите их отдельно, поскольку не все они могут быть выполнены для некоторых типов поставки ПО. Уточните сроки и периодичность создания бэкапов, а также уточните, платная эта услуга или нет.
  • Техническая поддержка. Мы рекомендуем у всех поставщиков CRM на первый год покупать пакет платной приоритетной поддержки так вам будет гораздо спокойнее. В любом случае, убедитесь, что техническая поддержка есть и уточните границы её оказания.
  • Облако или десктоп. Вечный спор из разряда Apple vs Samsung, Canon vs Nikon, Linux vs Windows. Если коротко, то десктоп в конечном итоге дешевле, местами безопаснее и быстрее в работе, лицензии принадлежат вам и не пропадут вместе с вендором. Облако удобнее для молодых, начинающих команд, когда не требуется персональное внедрение или доработка. Масштабируемость у обоих типов поставки CRM одинаковая.

Главные ошибки пользователей при описании требований


  • Упираться в мелочи. Как правило, почти любую мелочь можно настроить, гораздо важнее обратить внимание на то, как CRM согласуется с вашими бизнес-процессами. Если вы считаете самым важным в CRM дашборд с данными или возможность заменить лого разработчика на своё (кстати, в RegionSoft CRM легко), пообщайтесь с коллегами они помогут вам собрать требования, весьма красочно описав все недостатки своих бизнес-процессов.
  • Превращать требования к ПО в список покупок. Вы внимательно читаете все отзывы, социальные сети, Хабр, другие порталы, смотрите демо-версии всех CRM-систем и методично записываете всё, что вас хоть как-то заинтересовало, а затем весь этот длинный список вываливаете на наиболее подходящего вендора. А он, бедный, не понимает, почему должен разработать корпоративный портал, систему управления претензиями, модуль бухучёта и систему контроля трафика и документооборота для небольшой торговой компании в одном флаконе.

Выбирайте только то, что вам реально нужно и с чем вы можете работать. Потому что мы для вас при определённом уровне оплаты можем и экраноплан спроектировать, но а) это будет дорого; б) зачем он вам? В общем, выбирайте CRM-систему для нормальной рабочей жизни, а не для любования набором модулей и возможностей это может просто не окупиться.

  • Включать в требования фантазии и желания. Указывайте в требованиях то, что вы реально хотите сделать в бизнесе и будете использовать; задачи, поставленные в вакууме и в отрыве от реальности, причинят вред: вы убьёте время на их обсуждение и не получите результат.
  • Говорить с вендором, как с роботом. Если вы общаетесь непосредственно с разработчиком CRM (а не с партнёрской сетью), то знайте: мы не только программисты и инженеры, мы прежде всего такой же бизнес, как и вы. Поэтому расскажите о ваших проблемах, мы их отлично поймём и подскажем, как CRM эти проблемы решит. Мы не просто поставщики решений, в большинстве случаев мы сочетаем рассказ о CRM с разбором проблем вашего бизнеса. Поэтому говорите с разработчиками на обычном, человеческом языке. Скажите, почему вам вдруг стала интересна CRM-система и мы объясним вам, как её внедрить лучшим образом.
  • Быть негибким и упрямым в каждой формулировке. Обращайте внимание на то, как вендор предлагает решать ваши задачи у него уже есть опыт работы в сотнях проектах автоматизации и его инженеры нередко предлагают наиболее эффективное решение из всех возможных. Например, клиент может настаивать на требовании нотации BPMN 2.0 для описания процессов (потому что её хорошо продавали на конференции для CIO) и не признавать альтернатив, а потом попробовать удобный нативный редактор бизнес-процессов и убедиться, что с ним ВСЕ его сотрудники смогут справиться с бизнес-процессами. Выбирать удобные и практичные, а не модные и дорогие решения идеальная практика для малого бизнеса, который тратит на автоматизацию свои деньги, а не бездонный бюджет корпорации.
  • Говорить о CRM в целом, а не о конкретной системе. Во время общения с вендором говорите именно о его CRM-системе, запросите подробную презентацию, задавайте подробные вопросы по существу. Так вы сможете понять, какие задачи вашего бизнеса сможет решить эта конкретная CRM-система.

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


И напоследок, простой способ определить, удалось ли внедрение CRM: если вы используете CRM и скорость бизнес-процессов выросла, внедрение проведено правильно и ваш бизнес стал эффективнее.



(осторожно, 77 МБ)

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

**Биллинг должен запускаться по моему желанию, желание выражается на мобильнике биллинг должен запускаться вручную сотрудником АСУ после получения от сотрудника коммерции СМС о завершении расчётов с партнёрами.
Подробнее..

Как первокурсники Питерской Вышки за семестр написали торрент-клиент, анализатор кода, фоторедактор и не только

26.06.2020 14:09:33 | Автор: admin
Учиться программированию, изучая только теорию, это то же самое, что учиться играть на рояле, слушая лекции об игре на рояле. Первокурсники Прикладной математики и информатики в Питерской Вышке начинают изучать C++ в первом семестре. В дополнение к домашним работам с февраля они пишут на С++ семестровые командные проекты. Тему ребята придумывают самостоятельно, от игр и игровых движков до собственного анализатора кода.

Под катом подробности внутренней кухни: рассказ о том, как была устроена работа над проектами.



Кратко: каждой команде назначили менторов из числа действующих разработчиков или студентов старших курсов с опытом работы в IT-компаниях. Еженедельно первокурсники рассказывали о прогрессе и сложностях, с которыми пришлось столкнуться, в анкете и во время созвона с ментором. Чтобы команды потренировались выступать публично (а заодно чтобы установить дедлайны, к которым нужно готовиться), мы организовали две предзащиты. На финальной защите все команды успешно представили проекты, средний балл студентов 9,0 по 10-балльной шкале.

Теперь подробнее:

Об организаторах


Мы Наташа Мурашкина, Саша Орлова и Оля Лупуляк студентки старших курсов Прикладной математики и информатики в Питерской Вышке. Мы занимались организацией проектов под руководством куратора направления и лектора курса по С++ Егора Суворова.

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

О проектах


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

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


Демо-видео проекта Fivaproljo (мультиплеерный платформер)

К концу семестра необходимо было получить хотя бы MVP проекта, но многие команды успели добавить больше функциональностей, а кто-то даже написать тесты и оформить страницу на GitHub с описанием и инструкцией по запуску. Примеры: Моделирование и визуализация динамических систем, Анализатор кода UB-tester tool, Компьютерная версия игры Колонизаторы.

Подготовка


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

Ментор это сотрудник IT-компании или студент старших курсов с опытом промышленной разработки. Менторы помогали с распределением задач и решением технических проблем. Они еженедельно созванивались со студентами, чтобы обсудить прогресс и составить план работ на следующую неделю. В число менторов вошли стажеры и сотрудники JetBrains, Яндекса, ВКонтакте, Huawei, Google, Delightex, VeeRoute и других компаний, преподаватели Летней компьютерной школы (ЛКШ), а также студенты нашего факультета, московского кампуса Вышки и кафедры КТ университета ИТМО.

В качестве эксперимента мы даже пригласили мета-ментора (ментора для ментора): опытный сотрудник Google наставлял нашего старшекурсника в менторстве команды.

Работа в течение семестра


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

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

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

Воркшопы


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

Идея проводить репетиции не нова, и в нашем случае мы вдохновлялись воркшопами по публичным выступлениям, в которых Наташа участвовала во время стажировки в Google.

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

Структура презентации для воркшопов


  • Титульный слайд
  • Введение в область
  • Краткое описание проекта
  • Сравнение с аналогами
  • Сравнение технологий
  • Разбиение на подзадачи для каждого участника (по слайду на участника)
    • Описание подзадачи, решение, выводы
  • Описание текущего состояния проекта (что было сделано с начала)
  • Описание прогресса с предыдущей презентации
  • Планы до конца разработки
  • Можно сделать демо-видео не длиннее 30 секунд

Кстати, в блоге Питерской Вышки на Хабре уже есть инструкция по подготовке коротких докладов от декана нашего факультета Александра Владимировича Омельченко.


Демо-видео проекта Моделирование и визуализация динамических систем

Как оценивали вклад каждого участника


Здесь нам помогали коммиты студентов на GitHub и анкеты менторов.

К первому воркшопу и к защитам мы попросили студентов залить код проекта на GitHub. Количество строчек кода это, конечно, нечестная метрика, и нельзя судить только по ней, но ее мы использовали как первый фильтр. После вчитывались в содержание.

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

Итоговая оценка каждого студента за семестр складывалась из трех частей:

  • 30% работа в течение семестра. Для хорошей оценки нужно вовремя сдавать анкеты.
  • 35% оценка ментора. Для хорошей оценки нужно, чтобы ментор оценил прогресс.
  • 35% оценка комиссии на защите. Для хорошей оценки нужно, чтобы в итоге что-то получилось.


Итоги


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


Скриншот с защиты проекта TorrentX

Мы довольны результатами ребят. Трое студентов (из 61) получили оценку удовлетворительно, все остальные хорошо и отлично. Средний балл 9,0 по 10-балльной шкале.

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

Больше половины команд отважно согласились опубликовать свои финальные презентации и короткие демо-видео с защит. На всякий случай напомним, что проекты учебные и разрешалось даже изобрести велосипед с квадратными колесами. На старших курсах проекты уже посерьёзнее: раз, два, три.

Менторы, судя по обратной связи, получили удовольствие от работы.

Как и мы :) Так что в следующем году планируем продолжить.

Планы на будущее


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

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

  • Улучшить матчинг команда ментор, возможно, ввести собеседования между командой и ментором и маленькие тестовые задания. Учитывать пожелания менторов руководить более подготовленной (требует больше знаний) или менее опытной но не менее старательной! командой (требует лучших управленческих навыков).

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

  • Давать обратную связь менторам и студентам, даже если все идет хорошо, чтобы не казалось, что анкеты отправляются в пустоту.

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

И еще +100 заметок, которые мы бережно сохраняли в течение семестра.

Если вы хотели бы на волонтёрских основах побыть ментором студентов-первокурсников в следующем году, заполните форму или напишите нам в Телеграме (@murfel). Будем рады!
Подробнее..

Восемь самых популярных книг по Agile, Scrum и Kanban

25.06.2020 14:15:14 | Автор: admin
Наша команда знакома с гибкими методологиями разработки, двухнедельные спринты наше все. Недавно руководство решило распространить наш опыт на другие подразделения и попросило нас помочь в этом деле. Трезво оценив обстановку, мы поспешно отказались от этого предложения, но обещали подкинуть литературы, чтобы коллегам было с чего начать.

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



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


Как растет спрос на гибкие методологии


Раз уж всплыл этот вопрос, нам стала любопытна динамика интереса к Agile, Scrum и Kanban внутри нашей платформы. Для этого подняли статистику по всем мероприятиям в Точках кипения и сделали поиск по трем основным ключевым словам. Отредактировав вручную финальные списки, получили любопытную картину.

Начнем с Agile:


В 2019 году мы зафиксировали скачкообразный рост. Похоже, 2020-й не станет исключением. Пунктиром наш прогноз до конца года.

А тут разбивка по месяцам. Особенно впечатляет пик в апреле, во время самоизоляции:


Ну а в июне уже чувствуется сезонный спад активности.

По Scrum похожая ситуация, где по годам наблюдается даже более быстрый рост:


Хотя по месяцам цифры достаточно ровные:


А вот с Kanban все скромнее: пять мероприятий в 2019 году и три за первые пять месяцев 2020 года.

Далее мы решили оценить, насколько активность в Точках соответствует общим тенденциям роста интереса к Agile-тематике.

Мы взяли яндексовский WordStat и посмотрели динамику числа запросов по соответствующим ключевым словам за последние полгода:


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

Итак, возьмем статистику по количеству книг с упоминанием наших терминов по году издания. Получается вот такая картина:


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

В поисках правильных критериев оценки


Самый очевидный способ собрать список топовых книг по Agile и посмотреть, что советуют гуру этого направления. Это будет субъективная подборка, и доверие к ней сравнимо с доверием к самим гуру. Но для формирования шорт-листа и последующего статистического анализа самое то.

Вот так выглядит один из субъективных рейтингов, который нам встретился:
Лучшие книги по Agile, Scrum и Kanban, по версии одного из экспертов
ФИО автора
Название книги
1
Джефф Сазерленд
Scrum. Революционный метод управления проектами
2
Сборник
Канбан и точно вовремя на Toyota. Менеджмент начинается на рабочем месте
3
Майк Кон
Scrum: гибкая разработка ПО
4
Джефф Сазерленд, Кен Швабер
Софт за 30 дней. Как Scrum делает невозможное возможным
5
Дженнифер Грин, Эндрю Стиллмен
Постигая Agile
6
Зузана Шохова
Путь скрам-мастера
7
Майк Кон
Agile: Оценка и планирование проектов
8
Юрген Аппело
Agile-менеджмент. Лидерство и управление командами
9
Стивен Деннинг
Эпоха Agile


В итоге после объединения различных списков из разных источников удалось собрать шорт-лист из 22 книг. Как понять, какие из них наиболее полезные?

Вариант 1: посмотреть рейтинг книг по отзывам на сайтах, посвященных книгам. Их можно найти, например, на Litres.ru, Livelib.ru, Ozon.ru. Есть также сайт Bookmate.com, где пользователи отмечают, какие книги они прочитали, и оставляют рекомендации. Для нас интересно количество этих рекомендаций.

Если свести все данные в единую тепловую карту, получится вот такая картина.

Рейтинг книг на основании оценок пользователей специализированных сайтов


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

Продолжаем искать более объективные метрики.

Вариант 2: посмотреть на популярность книг по числу запросов в Яндексе и количеству страниц, на которых эти книги упоминаются.

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

Рейтинг книг на основании количества упоминаний


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

Вариант 3: создать сводный рейтинг на основании нескольких метрик обоих типов. Выбор этих метрик наше субъективное решение, здесь вы можете критиковать и предлагать свой набор.

Итак, мы выбрали для себя пять метрик, по каждой из них отсортировали книги. Затем 10 лучшим в каждом чарте присвоили по 1 баллу. Если значение метрики одинаковое у 10-й и 11-й книг, даем баллы обеим. Суммируем баллы и сортируем по их возрастанию.

Метрики, на которых остановились мы: рейтинг Livelib как самый полный, упоминания на сайте HSE, количество запросов в апреле, количество страниц с книгой в Яндексе и Вот здесь мы решили использовать еще один интересный параметр количество пользователей, прочитавших книгу на Bookmate, так как он показался более наглядным, чем количество положительных оценок.

Вот что получилось:


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

Кратко расскажем о каждой из них.

1. Джефф Сазерленд. Scrum. революционный метод управления проектами




Книга основателя Scrum пользуется высокой популярностью с 1995 года. Она пережила множество изданий и доступна в нескольких переводах. На 280 страницах хватает воды, но есть и четкое описание придуманной автором методологии. Правильнее будет именно с нее начинать свое знакомство со Scrum.

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


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

2. Канбан и точно вовремя на Toyota. Менеджмент начинается на рабочем месте




Это перевод учебных материалов специалистов компании Toyota к семинарам по производственной системе из далеких 1970-х годов. Как Сазерленд по Scrum является своеобразным евангелием, так и эта книга стала точкой отсчета для Kanban-подхода.

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


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

3. Майк Кон. Agile: Оценка и планирование проектов




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

Подход многих руководителей проектов можно представить как планирование, планирование, планирование выполнение. Agile-подход это планирование выполнение адаптация, планирование выполнение адаптация. Чем выше неопределенности проекта, тем важнее применение agile-подхода для успеха.


Упор в книге делается на две составляющие успеха любого проекта планирование и оценку. Книга немаленькая более 500 страниц, но потраченное время стоит полученных знаний. Между прочим, именно эта книга чаще всего упоминается на сайте ВШЭ.

4. Дженнифер Грин, Эндрю Стиллмен. Постигая Agile




Этот объемный труд (450 страниц) включает в себя описание всех основных agile-методологий: Scrum, Kanban, Lean и XP (eXtremal Programming). Книга легко читается, методологии даются несколько поверхностно, в обзорном режиме.

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


Для знакомства самое то. Постоянные повторения одного и того же призваны занести в память читателей самые важные моменты.

5. Хенрик Книберг. Scrum и XP: заметки с передовой




Эту книгу непросто найти в русскоязычном переводе, но это одно из лучших практических пособий по Scrum в области разработки ПО. Практические советы, наглядные примеры все, как мы любим.

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


Книга небольшая, в сети можно найти перевод, сделанный энтузиастами из Agile Ukraine.

6. Борис Вольфсон. Гибкое управление проектами и продуктами




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

Закон Паркинсона: любая работа увеличивается в объеме, чтобы заполнить все отпущенное на нее время.


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

7. Майк Кон. Scrum: гибкая разработка ПО


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

Scrum-командам приходится отвыкать мыслить в категориях моих задач и ваших задач и привыкать мыслить в категориях наших задач.


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

8. Дэвид Андерсон. Канбан. Альтернативный путь в Agile




Замыкает наш топ одна из ключевых книг по Kanban. Для первого знакомства, правда, она не подходит: слишком глубоко все разжевано, много тонкостей, которые будут интересны уже погруженному в тему читателю. Зато те, кто ее осилит (и пару раз перечитает), смогут включиться в канбан.

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


Стоит обратить внимание, что здесь Kanban рассматривается в разрезе разработки ПО, что делает книгу полезной именно для ИТ-продуктологов, разработчиков и руководителей проектов.

Согласны ли вы с нашим топ-8? Какие книги еще маст-хэв для тех, кто изучает Agile? Если вам есть чем поделиться или покритиковать, пишите в комментариях этим вы поможете другим в поиске знаний и добавите себе кармы.
Подробнее..

Руководитель о двух головах

26.06.2020 16:08:22 | Автор: admin
В IT характерно идти путем оптимизации и получать максимум от имеющихся ресурсов. Владельцы бизнеса тщательно подбирают топ-менеджеров, а HR-специалисты стараются не раздувать штат. Поэтому, например, в отрасли распространены многоэтапные собеседования, с целью взять лучшего кандидата по сочетанию положительных и отрицательных качеств, подходящего для выполнения конкретных задач, с учетом особенностей конкретной команды. При этом в каждой IT-компании есть своя история развития и примеры управленческих решений, которые также помогли оптимизировать работу талантливых ребят и внедренные ими процессы.

В статье мы рассказываем о системе, реализованной в Plarium Krasnodar: она предполагает разделение полномочий, ответственности и зон влияния между руководителем и координатором. Материал может быть полезен менеджерам разного уровня, а также специалистам по управлению, которые интересуются темой или планируют реорганизацию.

image

Привет, Habr. Меня зовут Дарья Меньшикова, я Head of Customer Experience & Support Division студии Plarium Krasnodar.

7 лет назад я начала работу с небольшой командой из 5 человек. Сейчас структура состоит из 83 сотрудников в офисе и около 100 удаленных специалистов, которые формируют 14 команд и выполняют функции для покрытия разных потребностей бизнеса в зоне post-production.

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

Вот как это работает

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

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

Стратегия и тактика это функции, предполагающие противоположные взгляды на цели и результат.

Когда я поняла, что эти функции не могут быть равновелики в одном человеке, стало очевидно, что их нужно разделить между двумя разными специалистами. Любой руководитель департамента или команды в дивизионе должен брать на себя стратегическую функцию, то есть выбирать, куда и зачем идет его команда. Также он должен передавать это видение своему помощнику координатору (не путать с помощником руководителя в классическом понимании), который будет искать, каким образом команда туда придет, отвечая на вопросы: с помощью чего, используя какие ресурсы?

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

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

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

Есть такие понятия, как цена и ценность. Бывает, что стратеги, особенно талантливые, чересчур увлекаясь проработкой направления развития, не учитывают, что за определенную ценность они могут заплатить огромную цену. Удачное ли сейчас для этого время? Можем ли мы себе это позволить? На такие вопросы и отвечает координатор.

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

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

Кто же он координатор?

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

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

Не PM. Project Manager в большей степени выполняет функции администратора: фасилитирует процессы, распределяет и собирает задачи, контролирует их реализацию и сроки выполнения, иногда налаживает коммуникацию между отделами или специалистами. Классическая зона принятия решения у PM ограничена по сравнению с координатором: последний помимо перечисленного несет полную ответственность за тактическое развитие команды.

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

Координатор это руки, лид это голова.

Обладает ли координатор властью? Безусловно: его власть в сфере принятия тактических решений. Лид контролирует только результат, не вникая в то, как координатор этого результата добился. Повторюсь, руководитель задает направление куда мы идем, зачем, почему, а как уже дело координатора.

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

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

Что же входит в должностные обязанности координатора? Зависит от его грейда. Посмотрим на должностную сетку.

image

Чем выше в иерархии должность координатора, тем большими полномочиями он наделен. Здесь есть один важный нюанс, касающийся стратегии и тактики. Поскольку Executive Director работает на уровне всего дивизиона, его зона ответственности шире, чем у Executive Lead, который работает на уровне департамента. Так как масштаб стратегии дивизиона больше стратегии входящих в него департаментов, тактика дивизиона очень часто перекликается со стратегией департаментов (соотношение дивизиона, департаментов и команд см. в схеме ниже).

image

Рассмотрим обязанности координатора на высшей в карьерной сетке должности Executive Director. Его функции можно разбить на 5 больших групп.

  1. Стратегия и тактика управления. Планирование работ с руководителями департаментов для достижения целей дивизиона. Изучение трендов и новых подходов в управлении сотрудниками, командообразовании и эффективном ведении бизнеса.
  2. Организация. Координирование при выполнении общих задач департаментов внутри дивизиона.
  3. Развитие команд. Участие в адаптации новых сотрудников и развитие молодых руководителей в дивизионе. Работа с сеньорами, лидами команд. Участие во всех этапах подбора сотрудников и присутствие на собеседованиях. Создание рабочей атмосферы в командах дивизиона и ее мониторинг. Руководство вспомогательными командами дивизиона.
  4. Взаимодействие. Ситуативная работа с топ-менеджментом краснодарской студии. Налаживание коммуникаций с другими студиями Plarium. Регулярное общение и консультации с юристами, в том числе по вопросам пользователей.
  5. Контроль. Участие в подготовке отчетности для вышестоящих руководителей. Определение и контроль сроков по стратегическим задачам дивизиона.

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

Какой минимальный набор качеств должен быть у координатора? Как разглядеть эти качества в сотрудниках или кандидатах?

  • Умение видеть суть вещей, обладание внутренним ощущением того, как правильно выстраивать процесс, исходя из формулировки задачи и требований руководителя, внимательность и пунктуальность.
  • Поскольку на этой должности процессы касаются разных людей, команд или даже департаментов, необходим хорошо развитый навык коммуникации. Компания большая, в ней работают специалисты с разным характером, строем психики и жизненным опытом. Чтобы эффективно выстраивать процессы, координатору нужно уметь находить общий язык со всеми. Тут может помочь знание типологий личности например, типов информационного метаболизма человека (соционика), типов личности по В.Пономаренко (профайлинг) и др.
  • При этом каждый координатор должен иметь эмоциональный стержень, быть психологически зрелым. Несмотря на то, что он работает с процессами, ему необходимо обладать определенным уровнем эмпатии и владеть этическими нормами. Большинство процессов в зоне ответственности координатора завязано на людях, поэтому отношение к ним должно быть базово хорошим. При наличии эмоциональной зрелости и хорошего отношения формируется частичная психическая абстрагированность от внешней фрустрации, то есть стрессоустойчивость. Это и позволяет при коммуникации чаще оставаться эмоционально нейтральным и достигать нужных целей для бизнеса.
  • А чтобы понимать, с кем и когда следует коммуницировать, необходимо хорошо понимать приоритеты. Видеть, в какой последовательности лучше выполнять задачи. Для правильной приоритизации нужно обладать наиболее важной информацией по каждой выполняемой задаче, чтобы внезапное появление новых данных не привело к переносу срока или потере в качестве. Это возвращает нас к первому пункту списка умение выделять суть.

Это для вас? Действуйте!

Система лид координатор предполагает диалог. Если вы любитель монологов, координатор вам не требуется.

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

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

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

Перевод Трехступенчатый фреймворк для решения проблем

26.06.2020 18:17:05 | Автор: admin


От автора перевода

В компании ВсеИнструменты.ру каждое бизнес-подразделение инициирует проекты, направленные на развитие компании, и те из них, для реализации которых необходимы изменения в IT-системах, приоретизируются и согласовываются совместно с IT. В ходе очередной сессии обсуждения проектов, планируемых на следующий квартал, пришло понимание простой истины: количество проектов всегда кратно больше, чем ресурсов в IT. И из этого следуют два не менее простых вывода.
  1. Мы никогда не сможем взять в работу все проекты, которые хотелось бы.
  2. Нужно научиться правильно их выбирать.



Уверен, что с аналогичными проблемами сталкивается абсолютное большинство продуктовых компаний. В качестве рабочего инструмента для решения этих проблем полезным представляется подход, описанный в статье Ленни Рачитски, product lead Airbnb.

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

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


Первые наработки запущенного продукта, дающие возможность путешественникам Airbnb находить мероприятия, в которых можно участвовать вместе с другими путешественниками

Лично я извлек из этого отличный урок. Но самое главное этот опыт развил во мне привычку и понимание важности правильной формулировки проблем. Среди многих причин, повлиявших на провал проекта, основной послужило изначальное непонимание проблемы, которую надлежало решить. Мы слишком поздно заметили, что настоящая проблема, которую нам надлежало решить, была не путешественники хотят тусоваться с другими путешественниками, а путешественники хотят находить интересные, нетуристические возможности для времяпрепровождения. Тусоваться с другими путешественниками это лишь одна из таких возможностей, и не самая значимая. К счастью, другая команда определила эту потребность и в конце концов запустила гораздо лучшее решение Airbnb Experiences несколькими годами позже.



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

  • Шаг 1. Кристаллизация проблемы
  • Шаг 2. Согласование проблемы с командой и стейкхолдерами
  • Шаг 3. Постоянный возврат к проблеме



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

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



Шаг 1. Кристаллизация проблемы


Начните с ответа на эти вопросы о своем проекте.

  • Описание: что это за проект?
  • Проблема: какую проблему он решает?
  • Почему: как мы поняли, что это реальная проблема и ее нужно решать?
  • Успех: как мы узнаем, что проблема решена?
  • Аудитория: для кого мы делаем это?
  • Что это: как будет выглядеть реализация в продукте?

Описание: что это за проект?


Это краткое описание идеи. Люди, читающие его, смогут быстро понять суть. Будьте кратки.

Проблема: какую проблему он решает?


Сама постановка проблемы является настолько основополагающей, что стоит потратить на это дополнительное время. Поразмышляйте о проблеме гипотетически. Какую, по вашему мнению, проблему вы решаете и почему? Вы добавите больше контекста позднее.

Назовем ключевые характеристики правильной постановки проблемы.

  1. Проблема кратка. Цель описать проблему одним предложением. Чем больше вам требуется объяснений, тем менее ясной становится проблема в конечном итоге.
  2. Сфокусирована. У нас есть единственная ясная проблема, которая может быть решена одной командой и в разумные сроки. Часто очень полезно привести несколько примеров других проблем, которые вы НЕ решаете.
  3. Связана с неудовлетворенной потребностью. Сосредоточьтесь на потребностях пользователя или бизнеса. Тут крайне полезно использовать вот этот фреймворк.
  4. Включает ответы на вопрос что и почему. Что идет не так и почему это проблема? Возможно, вам придется вернуться сюда в следующей секции.
  5. Не зависит от решения. Подавляйте в себе желание слишком быстро перейти к решению проблемы.

Хорошие примеры постановки проблемы

  • Водители службы такси Lyft часто отклоняют заказы, потому что они находятся слишком далеко от клиента.
  • Хозяева жилья на Airbnb чувствуют разочарование, потому что они хотят развиваться, но не знают, как это сделать.
  • Пользователи слишком часто уходят на финальном этапе регистрации.

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

  • Количество пользователей растет медленно. [Что не так: проблема слишком широка. О стратегии приближения большой картины можно прочитать здесь и здесь. К тому же не учитываются потребности пользователя.]
  • Создать программу лояльности. [Что не так: это решение. Какую проблему мы хотим решить?]
  • Пользователи не доходят до конца регистрации. [Что не так: недостаточная фокусировка, упущена предполагаемая причина. Нужно опуститься на один уровень ниже.]

Почему: как мы поняли, что это реальная проблема и ее нужно решать?


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

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

Несколько советов для этого шага.

  1. Изучите количественные и качественные доказательства. Соберите все данные, которые указывают на то, что это действительно реальная и важная проблема.
  2. Качество важнее количества. От 3 до 5 прямых фактов лучше дюжины косвенных. Во втором случае ваши выводы будут слабее, так как они будут основаны на второстепенных и не имеющих отношения к делу фактах, выглядящих как куча доказательств. Лишний перфекционизм также ни к чему.
  3. Сыграйте сами с собой в адвоката дьявола. Попытайтесь убедить себя, что это совершенно незначимая проблема. Какие пробелы имеются в ваших доказательствах? Действительно ли доказательства соответствуют тому, что вы думаете? Проверьте себя.

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

Успех: как мы узнаем, что проблема решена?


Вы достигли того, что планировали достичь? Как вы узнаете? Ответьте на этот вопрос и запишите ответ.



Этот критерий становится невероятно важен на протяжении всего проекта, так как он помогает принимать решения и расставлять приоритеты. Фича X увеличивает шансы достичь поставленной цели? Если нет, не делаем ее.

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

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

  • Постарайтесь получить конкретное число, например: 10% прирост показателя X; 50% уменьшение показателя Y.
  • Цель должна быть достижима, но амбициозна. Достижение какой цели приведет вашу команду и руководителей в восторг?
  • Если вы не смогли придумать метрику для своей цели (думать нужно долго и напряженно), опишите, как будет выглядеть мир в случае успеха проекта. Сделайте это критерием успеха.

Аудитория: для кого мы делаем это?


Тут все довольно очевидно. Мы редко делаем что-то сразу для всех. Это для новых или вернувшихся пользователей? Это для случайных или постоянных пользователей? Это для пользователей сайта или мобильного приложения? И тому подобное.

Что: как будет выглядеть реализация в продукте?


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

Шаг 2. Согласование проблемы с командой и стейкхолдерами


Видели ли вы билборды Чиптолле вдоль шоссе (картинка ниже)? Год назад мой коллега Питер указал на хитрость этой рекламы каждый из нас представляет свой идеальный буррито внутри фольги. Мы все видим то, что хотим увидеть.



Понимание проблемы похоже на буррито в фольге. Каждый член вашей команды имеет свою версию проблемы в своей голове. Иногда они почти полностью совпадают. Иногда они абсолютно разные. Чем крупнее и сложнее проект, тем чаще они различаются. Ваша задача искоренять эти расхождения как можно раньше и как можно чаще. Вскройте упаковку и убедитесь, что все согласны с тем буррито, которое внутри. К счастью, у нас есть великий документ, который мы создали на первом шаге. Он сделает вашу работу в 10 раз проще.

Я обычно подхожу к этому шагу так.

  1. Возьмите документ, созданный на первом этапе (это может сделать и любой член вашей команды, вовлеченный в эту проблему).
  2. Поделитесь им со всей командой. Соберите обратную связь. Доработайте документ с учетом полученной обратной связи и снова предоставьте его на общее обозрение.
  3. Если обратная связь сходится и команда выглядит синхронизированной отлично. Если нет, соберите всех вместе и обсудите разногласия.
  4. Когда согласие внутри команды будет достигнуто, синхронизируйтесь в понимании проблемы со стейкхолдерами. Важно, чтобы ваша команда и люди, которые будут оценивать результаты, одинаково понимали проблему, которую вы решаете, до того, как вы плотно приступите к работе по проекту.
  5. Соберите команду и снова произведите ревью постановки проблемы. Отыщите ответы на нерешенные вопросы и убедитесь, что у команды есть все необходимое, чтобы начать работать.

Шаг 3. Постоянный возврат к проблеме


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

image

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

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

Избежать этой ловушки помогут полезные привычки.

  1. При каждом ревью проекта удостоверьтесь, что исполнитель начинает с постановки проблемы. Если это не очевидно, задайте вопрос: Какую проблему мы пытаемся решить?.
  2. При каждом отчете о ходе проекта перед стейкхолдерами возвращайтесь к постановке проблемы. Убедитесь, что у всех остается одинаковое ее понимание.
  3. Перед финализацией проекта спросите себя: Чувствую ли я уверенность в том, что мы готовы решить проблему, которую планировали решить изначально?.

И в заключение


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

Проблемы постоянны в жизни.
Когда вы решаете проблему здоровья, приобретая абонемент в спортклуб, вы создаете новые проблемы: вставать раньше, чтобы прийти в клуб ко времени, принимать душ и переодеваться для работы, после того как потели в течение 30 минут на эллиптическом тренажере, так как не хотите вонять на весь офис.
Когда вы решаете проблему недостатка времени для общения с партнером, назначая вечер среды датой свидания, вы создаете новые проблемы: как, например, придумывать, что вы будете делать каждую среду, которую вскоре начнете оба ненавидеть
Проблемы никогда не кончаются они только меняются и/или модернизируются.

Марк Менсон. Тонкое искусство пофигизма

Время, потраченное на совершенствование навыков решения проблем, это время, проведенное с пользой.

Очень рекомендую прочитать следующие 5 книг.



  1. Deep Work (Кэл Ньюпорт. В работу с головой. Паттерны успеха от IT-специалиста)
  2. The Subtle Art of Not Giving a F*ck (Марк Менсон. Тонкое искусство пофигизма)
  3. Good Strategy, Bad Strategy (Ричард Румельт. Хорошая стратегия, плохая стратегия. В чем отличие и почему это важно)
  4. Measure What Matters (Джон Дорр: Измеряйте самое важное. Как Google, Intel и другие компании добиваются роста с помощью OKR)
  5. Lean Analytics (На момент написания статьи не переведена на русский)

От автора перевода

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




Взял фреймворк себе на вооружение. Для удобства использования разработал форму для кристаллизации проблем.

Выражаю благодарность нашему журналисту Анисимовой Татьяне и арт-директору Забегалову Алексею за помощь в редактировании и оформлении статьи.
Подробнее..

Тимлиды. Много и сразу. Как выбрать и развивать

26.06.2020 18:17:05 | Автор: admin
Всем привет! Меня зовут Андрей Новиков, я руководитель разработки в одном из подразделений компании Exness, и совместно с Леной Скворцовой, нашим HR BP, мы хотим вам рассказать про то, как выбираем тимлидов в командах разработки, как их развиваем и как растим под жарким кипрским солнцем.



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


Наша инфографика на 01/06/2020

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

  1. Найм сотрудников на Кипр всегда происходит медленнее, чем в СНГ, так как для многих релокация это серьезный шаг.
  2. В один момент нанять 79 тимлидов непростая задача, которая растянется на годы.
  3. Для наших инженеров стать тимлидом еще один путь развития, который позволяет ребятам, желающим в будущем занимать менеджерскую позицию, расти внутри компании.
  4. Этапы шторминга и притирания проходят гораздо быстрее с человеком, которого команда уже знает.

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

  1. Процесс выбора;
  2. Talentpool;
  3. Программа развития;
  4. IDP;
  5. Уроки и советы.


Процесс выбора


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

Для этого весь процесс мы разделили на несколько этапов:

  1. Самостоятельная подготовка;
  2. Собеседование;
  3. Калибровка результатов.




Самостоятельная подготовка


В качестве самостоятельной подготовки всем кандидатам из команды мы давали письменное задание подумать над вопросами: Если бы я стал тимлидом, что бы я изменил в команде прямо сейчас?, Почему я хочу стать тимлидом?, Какие проблемы и вызовы я вижу перед собой в новой роли?.
Ответы на эти вопросы очень важны, потому что с одной стороны, они заставляют еще раз задуматься над вопросом Действительно ли я хочу стать тимлидом?, порефлексировать над своим опытом, сильными и слабыми сторонами, с другой подсветить проблемы и области развития команды, которые видны в текущей роли.

Собеседование


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

  1. Какая мотивация у сотрудника стать тимлидом? Деньги, карьера, вызов, саморазвитие, признание?
  2. Какие сильные стороны есть у кандидата для роли тимлида?
  3. Что необходимо прокачать и изменить?
  4. Какие риски есть при назначении данного сотрудника на роль тимлида? Например, команда останется без единственного фронта, и нужно сразу открывать позицию на замену, или есть риск сильной демотивации другого кандидата?

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

Калибровка результатов


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

Talent Pool


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

Программа развития


Наша внутренняя программа рассчитана на шесть месяцев и составлена с учетом постепенного погружения инженера в его новую роль линейного менеджера команды. Мы соблюдаем баланс между быстрым погружением человека в роль и обучением навыкам, которые пригодятся в роли ТЛ с первых дней работы, и защитой от выгорания в абсолютно новой роли и новых взаимоотношениях с командой.
Программа развития тимлидов делится на два направления: базовый менеджмент и операционный менеджмент. Первое направление это менеджерский фундамент, который будет полезен любому менеджеру в любой организации. Второе направление это инструменты и подходы, которые используем именно мы, они также являются достаточно популярными, но не применяемыми повсеместно, или адаптированными под конкретную компанию.

Программа базового менеджмента



  • Развитие лидерства команды
    • Роли менеджмента
    • Цикл управления
    • Ситуационное лидерство
  • Навыки влияния
    • Управление вовлеченностью
    • Типы личностей
    • Избегание манипуляций
  • Навыки влияния и оценка деятельности
    • 1-1 встречи
    • Оценка 360
    • Как предоставлять негативный фидбек
  • Управление собственной продуктивностью
    • Приоритеты
    • Типы планирования
    • Энерджи-менеджмент
  • Мотивация
    • Мотивация или вовлечение
    • Теория мотивации
    • Gallup Q12

Программа операционного менеджмента


  • Инцидент менеджмент;
  • Гибкие методологии разработки (Scrum, Kanban);
  • Фасилитация встреч;
  • Процесс найма;
  • Процесс адаптации;
  • Увольнение;
  • Разбор сложный кейсов;
  • Зарплата.

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

IDP (Individual Development Plan)


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

Процесс составления и развития по IDP выглядит так:

  1. Подготовка. На первичной встрече тимлид и Learn & Development (L&D) специалист/ HR обсуждают те области, где сотрудник чувствует неуверенность/ хочет расти. Это беседа с примерами из ежедневной работы руководителя, цель которой понять, что конкретно хочется улучшить. Как в идеале выглядит результат? Чем это поможет бизнесу?

  2. Составление IDP. IDP это список книг, статей, подкастов, видео, фильмов, активностей для прокачки конкретного скилла. На каждый скилл, как правило, включаем чтение/ видео/ активность, чтобы, как говорится, и в теории, и на практике.
  3. Развитие. После того, как IDP готов, мы приступаем к работе над ним. Один раз в месяц тимлид и L&D специалист/ HR встречаются, чтобы посмотреть, работает ли IDP, стоит ли его подкорректировать, и чем еще можно помочь. IDP это рабочий инструмент, который может меняться и дополняться. Например, после результатов 360 мы часто дополняем IDP, если видим, что конкретная компетенция просела.

Как выбрать компетенции для IDP? Задача L&D специалиста и тимлида на первой встрече понять на примерах, какая компетенция нуждается в улучшении.
Обычно все компетенции в IDP попадают в три основные области скиллов в компании: business acumen (понимание бизнеса и отрасли), operational excellence (execution) и leadership (soft skills, так необходимые руководителю). Для тимлидов первая версия IDP в основном заключалась в работе над leadership, а именно people management.
Как мы измеряем прогресс? Как всегда фидбек! Это и личный фидбек от коллег, и результаты 360, и, конечно же, отзывы тимлидов про свое развитие.



Уроки и советы


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

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

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

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

Как найти идеальную работу в IT? Психологический подход. Ч1 Распознать Менеджера Из Ада Анализируя Описание Вакансии

29.06.2020 04:15:17 | Автор: admin


После подачи более чем трех сотен заявок на работу на совершенно разные позиции в разные компании в разных странах, я начал замечать явную закономерность в том, как описание вакансии напрямую отражает то, что Вас в действительности поджидает на рабочем месте. Не всегда можно легко и сходу понять что стоит за, и что действительно подразумевают HR, например, под пунктом стрессоустойчивость в списке требований к кандидату. В этой статье я хочу поделиться своим опытом по поиску идеальной работы, и теми навыками которые я приобрел после сотни собеседований из тех трех сотен заявок, упомянутых выше. Я хочу показать Вам как нужно анализировать описание вакансий перед трудоустройством, чтобы найти работу которая действительно будет подходить Вам по Вашим критериям идеальной работы. Здесь, мы будем рассматривать поиск работы как отдельную науку, с наглядными примерами.
Эта серия статей нацелена как на зеленых выпускников, только получивших диплом, так и на матерых синиоров, сменивших не один коллектив. Она также может быть полезна HR менеджерам как overview их деятельности со стороны для анализа ошибок и работы над ними.


Обо мне
А чтобы немного подкрепить силу аргументов которые я собираюсь привести в этих статьях, расскажу о вкратце о себе, и о моём отношении к IT и психологии. Эту секцию можно пропустить. Я оконочил два направления: психологию с уклоном в консультирование и software engineering (double major, для тех кто знаком с американской системой образования). На последнем курсе бакалавриата мне удалось немного попрактиковаться в психологическом консультировании, работая с реальными клиентами а также попрактиковаться в разработке во время написания веб приложения на питоне с фласком для автоматизации анализа психометрики. Сейчас я работаю нейро-дата аналитиком при институте нейроинформатики в Германии, и считаю что я вполне достиг цели в поиске своей идеальной работы.

Introduction



Итак, начнем. Первое, что стоит помнить при прочтении описания вакансий их писали люди. Масло-масляное, правда? Но гораздо важнее, затем понять кому именно дали задачу написать описание вакансии джуну HR / тимлиду / не джуну HR, но все равно мало понимающему что из себя представляет разработка итд. Такой анализ может быть очень полезен на дальнейших этапах трудоустройства. Я столкнулся с огромным количеством вакансий, в которых требуют невероятных навыков для Н-ной позиции, что часто приводило меня к заключению, что человек писавший это описание позиции не имеет ни малейшего представления о том, чего ждут от кандидатов (небольшой sidenote, зачастую и на более поздних этапах собеседований, даже относительно более компетентные сотрудники, чем джуны HR, тимлиды например, не понимают что именно они ждут от кандидатов на эту роль, но об этом в следующих частях статей из этой серии).

Неясные требования к кандидатам: Хотят чтобы умели всё и сразу, и за недорого



Неясное, обширное описание необходимых навыков очень хороший предварительный индикатор того, что Вас будут гонять и Вам придется заниматься задачами не входящими в область Вашей специализации. Например, среди тех трех сотен вакансий про которые я говорил вначале, было много вакансий на позицию backend разработчика, где требования вполне тянули на fullstack, к которому часто еще притягивали доменные знания и понимание ML/DL, а не backend. У менеджеров и в команде в целом должно быть четкое разграничение задач и понимание того, кто и чем занимается. Нельзя нанимать backend разработчика и заставлять его разрабатывать front, еще и вдобавок тренировать ML модели за зарплату backendщика. Если же, например, компания маленькая, и в команде не так много людей, что оправдывает такое использование кадров, то это должно быть в описании вакансии, ровно как и компания в таком случае должна уточнять что ищет не backend разработчика, а мальчика на все руки, ну или просто fullstack разработчика. Однако, ничто не идеально, и приходится мириться с тем что есть, и следовательно обращать внимание на такие детали при поиске работы.

Неясные требования к кандидатам: Сами не знают чего хотят


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

Требования:
Python 3.6
Django, Django-rest, Django-rq, Flask, Tornado, CherryPi;
MySQL / Postgres;
Знание docker / docker-compose;
Понимание работы http, https. REST, RESTful, SOAP;
Знание React Redux, AngularJS;

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

Основные требования: стрессоустойчивость;



Напоследок мой самый любимый пункт в списке требований к кандидату стрессоустойчивость. Это самый распространенный из контроверсивных пунктов которые можно встретить на сайтах по поиску вакансий. Что он может означать? Я до сих пор до конца не понимаю, какое именно личностное качество работодатели ищут в кандидатах под таким пунктом, но одно я знаю наверняка, есть несколько очень веских причин не устраиваться на работу, где есть такой пункт в описании. Во первых, нормальному, здоровому человеку, не страдающему мазохистскими наклонностями, не захочется стрессовать на работе. Вопреки всем мифам, работа НЕ должна приносить стресс! Работать должно быть приятно! Во вторых, это еще один индикатор того, что происходит в коллективе, и что из себя представляют задачи с которыми, Вам, возможно, придется работать. Есть бесконечное множество причин, почему рекрутеры ищут стрессоустойчивых кандидатов. Скорее всего, проектные менеджеры некомпетентны, и не умеют правильно назначать тикеты по скиллу и по количеству задач. Т.е. менеджер, возможно, не знает как управлять человеческими ресурсами, и как управлять коллективом. Другая причина возможно компания экономит на количестве сотрудников: в команде не хватает рук, и задач больше чем количество людей, которые с ними могут справиться, и всё постоянно горит. Компания может также экономить и на качестве сотрудников, нанимая тех, кто попросту запросил меньше заработной платы на интервью. В любом случае, весь смысл существования менеджеров чтобы рядовым разработчикам не приходилось стрессовать из-за задач которые на них кинули; в то время как основная задача тимлидов и управляющих отделами следить за тем, чтобы в команде было достаточное количество и качество сотрудников под проекты которые они собираются разрабатывать.

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

А что вы думаете по этому поводу? Буду рад обсудить с Вами в комментариях.
Подробнее..

Из песочницы Ключи к успеху ИТ-проекта

29.06.2020 22:07:32 | Автор: admin
Всем привет!

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



О себе


9 лет ИТ-консультант SAP ERP. Обязанности: проектирование, тимлидинг, тестирование и отладка, обучение, пилотирование.

Рамки применимости


Писал ориентируясь на проекты от 3-4 месяцев до 1 года со сложной межсистемной интеграцией.

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

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

Глоссарий


БА бизнес-аналитик
БЗ база знаний проекта
БТ бизнес-требования
ИТ архитектор и консультанты проектной команды
КП ключевой пользователь
МК младший консультант, эникейщик
ПР проектное решение
Прод продуктивная система
Разраб разработчик
СТ сценарии тестирования
СК старший консультант, проектировщик
ТЗ техническое задание

Ключи к успеху ИТ-проекта


Общий посыл налаженная коммуникация


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

Детальные и продуманные БТ


По БТ должно быть полное и синхронное понимание между бизнесом и ИТ. Для этого его должен составлять БА и КП (идеально, когда БА бывший КП).

Полный набор сценариев тестирования


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

Разделение труда внутри ИТ


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

Тоже касается содержания ТЗ/ПР в актуальном состоянии:

  1. СК пишет разрабу о корректировках и ставит МК в копию
  2. МК собирает и отражает изменения в режиме редактирования используя версионность
  3. СК принимает правки
  4. МК обновляет документацию в БЗ

Тестирование также следует делегировать МК.

Плохо знаю как вне SAP, но здесь очень часто используется принцип консультант-комбайн, который делает все (проектирование, тестирование, написание документаций)
В результате страдают качество, сроки (и деньги) и растут риски, связанные с тем, что все завязано на 1 человека.

Тестирование сценариев перед релизом


  1. Тестирование необходимо проводить в приближенной к проду среде (в идеале в копии прода).
  2. Обязательно участие людей, которые непосредственно будут работать с функционалом (желательно перед этим провести ликбез по решению).

Общее пространство для команд интегрирующихся систем


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

Техническая адекватность принимающей стороны


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

Идеально, если принимающее лицо отлично знающий бизнес человек с последовательной и структурой логикой.

Модератор на пилот


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

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

Разбиваем монолит на микросервисы

30.06.2020 08:17:02 | Автор: admin

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



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


Итак, ваша организация решила разбить старый, добрый монолит на микросервисы. Почему? Ясного ответа никто дать как правило не может, но в целом все начинают описывать как им плохо живется с монолитом. Да, релизные циклы действительно очень зацеплены за разные команды. А почему вы думаете, что в МСА по-другому? Кто-то говорит, что микросервисы гораздо лучше масштабируются. Ну можно сделать и так, а вам зачем это? Нет, может и надо, но вы понимаете зачем или просто подсмотренную фразу используете? Говорят, каждый микросервис гораздо менее требователен к ресурсам: памяти, базе данных и т.д. Ну и что? У вас деньги на сервера иссякли? Бизнес ценность-то в чем?
Коллеги, я не хочу сказать, что у МСА нет преимуществ. Эти преимущества есть. Но я хочу сказать, что какие бы цели вы ни ставили при старте проекта разбивки, вы их скорее всего ставите неправильно и никогда не достигните. Не достигните просто потому, что реализацией проекта у вас будут заниматься те люди, которые довели до состояния бездарно написанного кода ваш монолитный проект. При этом все подходы при реализации МСА настолько отличаются от монолитной, насколько телефонная лапша 20-го века отличается от сетевых технологий нынешнего 21-го века. И аналогия здесь действительно очень удачная. ТФоП доставляет в квартиру одну телефонную линию. Обрыв на любом участке линии приводит к выходу ее из строя. Сетевые технологии динамичны и позволяют строить альтернативные маршруты. Даже выход из строя 60% всей сетевой инфраструктуры страны в результате ядерной войны, не приведет к отказу оставшихся сетей.


Т.е., главное преимущество МСА перед монолитом это динамичность, которая способна приводить к чрезвычайной надежности системы. Тут надо пояснить: из самой МСА никак не следует, что она будет надежна. МСА лишь дает вам возможность строить надежные системы. Но это ваша ответственность заложить в архитектуру вашей системы надежность и дублирование функционала.


А сейчас разберем повсеместно встречающиеся ошибки при развитии микросервисной системы предприятия.


  1. Отказ от изменений бизнес-процессов
    Говорят, что любой бизнес реализует в коде свои бизнес-процессы. И, если вы 20 лет до этого строили свои бизнес-процессы на базе вашей монолитной архитектуры, то любая ваша попытка внедрить МСА будет заведомо обречена на провал. Просто потому, что для этого требуется менять бизнес-процессы.Пример? Сколько стадий согласования вопроса у вас существует в организации? Так вот, в микросервисной команде число таких стадий приближается к нулю. Подавляющее большинство вопросов решается внутри команды, реализующей микросервис. Команда не обязана выносить на корпоративный уровень вопросы о языке, на котором будет написан микросервис. Одни могут выбрать Java, а другие Python. Вы может быть даже сейчас не поверите, но этот вопрос является полностью в компетенции команды. И это потому, что в случае каких-то проблем, микросервис проще ПЕРЕПИСАТЬ, чем ПОДДЕРЖИВАТЬ.
    По моему опыту, разработка простейшего микросервиса при нормально поставленном производстве занимает неделю работы двух джунов, включая бюрократию по выводу его в пром, т.е. обходится компании, включая различные накладные расходы, примерно в 50-100 тыс. руб. Если у вас только аналитика занимает месяц работы 3 команд, то у вас нет никакой МСА в организации, вы опять скатываетесь в лютую монолитчину.
  2. Поручить руководство проектам опытным монолитчикам
    После того как вы отказались от модернизации своих бизнес-процессов, совершенно логичным является то, что вы поручаете новый проект очень опытному человеку, который показал себя с лучшей стороны и вообще знает все ваши бизнес-процессы. Возможно кто-то вам и нудел, что на старые проблемы должен взглянуть новый опытный человек, но вы отмахнулись от него как от глупой назойливой мухи. И вот он. Ваш новый/старый руководитель разработки на проекте. Не удивляйтесь, что результат будет тем же, что и раньше и даже хуже. Когда в МСА начинают применяться монолитные решения, ни к чему хорошему это не приведет. Именно в этот самый момент вы подписали смертный приговор вашему пилоту. Возможно, вы даже наберете опытных людей, которые уже сожрали стаю собак на микросервисных проектах, но это вас не спасет, просто потому что их начальник слушать не будет. Просто потому что у него мозги не заточены под МСА, а советы других он будет воспринимать как чудовищную глупость.
  3. Архитектура разрабатывается архитекторами без опыта разработки
    Вот сидит такой архитектор, который за свою жизнь не написал ни строчки кода и выдает распоряжения разработчикам. Очень часто, разработчики оказываются более квалифицированными чем он сам, но он как наполеончик отдает распоряжения. Распоряжения конечно же глупые. Примеры этих распоряжений смотрите дальше.
  4. Повторить функционал монолитной системы.
    Ну это же логично: надо сначала полностью воспроизвести то, что уже есть, а потом двигаться дальше. Воспроизвести все баги и костыли, все то дерьмо, от которого годами плюются разработчики.
    Мне одно не понятно: с чего эти архитекторы взяли, что потом кто-то даст денег на рефакторинг? Т.е. вы копируете вашу морально устаревшую систему, не привносите ничего положительного с точки зрения функционала и с этим 20 летним старьем вы будете жить еще как минимум 10 лет до следующего рефакторинга.
  5. Переиспользование кода
    Любой монолитчик знает, что код надо переиспользовать. Если сделал функцию User::toString, то в рамках МСА ее сейчас нужно выделить в отдельный микросервис и все 1000 других микросервисов будут ломиться к ней для сериализации каждого юзера. То, что первый же сбой в микросервисе положит всю систему в монолитах же такого не было.

Впервые с боевой микросервисной архитектурой я столкнулся в 2017 году. К тому времени система уже работала 7 лет и за это время произошла полная смена команды.
Сотни микросервисов. Документации никакой нет. Нет даже простого описания назначения каждого микросервиса. И вообще не понятен каков статус микросервиса: функционирует, деактивирован, экспериментальный и пр. В случае возникновения проблемы, трассировка микросервисов превращалась в сплошной кошмар. В итоге, в команде просто никто долго не держался. Текучка стала бичом команды. За 3 месяца команда могла просто обновиться полностью.
Это реальная история неудачно спроектированной микросервисной системы. Такой финал ждет подавляющее большинство пилотов, которые сейчас стартовали. А все из-за ошибок, которые я перечислил выше.


А сейчас я хочу рассказать как надо разрабатывать микросервисную систему.


  1. Проанализируйте свой предыдущий опыт, составьте список того, что считаете удачным, а что вам следует пересмотреть. Проведите опрос клиентов, пускай они запросят необходимые изменения в функционале. Ваша цель путем одного мелкого и ювелирно точного рефакторинга достичь нескольких бизнесовых целей. Ваша цель не переписывать одно и то же 10 раз, а создавать бизнес-продукт, который будет приносить деньги. Вы не просто должны сделать копию легаси-системы, а должны построить новейшую систему, которая выведет вас на передовой край ИТ отрасли. Зачем вам эти старые костыли?
  2. Пересмотрите свои бизнес-процессы. Если у вас любой agile всегда скатывается к жесткому водопаду, если согласования и аналитика занимают месяцы, то ваше производство ПО требует кардинальной модернизации. А для этого нужно ...
  3. найти специалиста с большим опытом разработки микросервисных систем. Пускай он не посвящен в ваши бизнес-процессы, но этот новый человек посмотрит на ваши застарелые проблемы свежим взглядом и даст действительно ценные рекомендации. Кроме того, только человек с реальным опытом микросервисной разработки способен предусмотреть те подводные камни, которые вам встретятся. Ваш опытный монолитчик только все запорет.
  4. Легаси-разработчики это ваш резерв, который в новой разработке сможет выступить ценным экспертным звеном. Но люди, которые пилили монолит в виде костылей, ни в коем случае не должны стать костяком разработки микросервисной системы и определять ее архитектуру. Монолитчиков должна ждать стажировка под руководством людей с опытом построения микросервисных систем. И главное что ждет монолитчиков это жесткий слом мозга и полная перестройка мышления.
  5. Каждый микросервис это не просто мелкая функция бэкенда. Это полный цикл разработки бизнес-функции. Одна команда полностью должна нести ответственность за всю разработку этой бизнес-функции как на фронтенде, так и в базе данных. Как только вы начинаете делегировать часть разработки другим командам, вы тут же начинаете погрязать в интеграциях. Интеграции в МСА это еще более дорого, ненадежно и неэффективно чем в монолите. Необходимо снижать их количество. В качестве микросервиса вполне нормально выбрать CRUD для какой-то сущности, например, сущности клиентского договора. Это нормально, если команда предоставит как бэкенд, так и фронтенд-микросервис (или библиотеку) для работы с договорами: список, создать, обновить, удалить. Главное это чтоб команда несла полную ответственность за то как эта функция будет работать на сайте и в мобилах.
  6. Не нужно заниматься фанатизмом при внедрении микросервисной архитектуры. При правильной микроархитектуре сервисов, вы сами решаете в какой форме выпустить приложение: в монолитной, микросервисной или бессерверной архитектуре. Ожидайте, что ваша бизнес-постановка может измениться в любой момент и вы должны с легкостью реализовать изменения. Гибкая разработка это то что просто без лишней болтовни должно реально применяться на всех уровнях.
  7. С недоверием относитесь к переиспользованию функционала. Наоборот, любой функционал должен дублироваться. Ваш выигрыш 10 гигабайт дисковой памяти никого не впечатлит, если справочник, который используют 30 микросервисов будет остановлен из-за сбоя, приведя к каскадному отключению всей микросервисной системы. Микросервисы должны КУПИРОВАТЬ сбои сторонних сервисов, а не усиливать их. И этот принцип это главная проблема для монолитчиков. После 20 лет работы с реляционными БД, после десятилетий опыта нормализации таблиц и структур данных в приложениях, очень сложно приучить себя к мысли, что дублирование, репликация, шардирование, денормализация это нормально и полезно для проекта, а переиспользование и нормализация это потенциально сбойные места, готовые положить всю систему.
  8. И вообще, что произойдет после сбоя одного из модулей? Вы просто должны моделировать все такие сбои и штатно обрабатывать их. Каскадное отключение всей системы это лишь один из сценариев. Неприятностей может быть много. Это в монолите все компоненты находятся в одном Jar-нике. В МСА каждый микросервис отделен ненадежными и компроментируемыми сетевыми коммуникациями. Это не плохо и не страшно. Это надо просто держать в голове при разработке и предусматривать сценарии разрыва этих коммуникаций.
  9. Если вы очень любите Spring, Hibernate и OracleDB, то скорее всего вы никогда не сможете построить надежную и быструю микросервисную систему. Spring был изобретен в годы становления монолитной архитектуры. Это огромный монстр, который даже в функции простого Hello World превратится в jar-файл размером в сотни мегабайт. Просто старт такого приложения растягивается на минуты. И эти гигабайты бессмысленного цифрового мусора будут пожирать ваши серверные ресурсы 24x7x365. Oracle, Postgres, MySQL это все жуткое старье, которое было построено из расчета, что база данных должна крутиться на одном сервере. Да, время идет и все эти базы данных обзавелись средствами масштабирования, но до сих пор они в этом вопросе совершенно неуклюжи и ненадежны. Существуют целые классы баз данных (NoSQL, NewSQL), которые создавались в парадигме Big Data, High Availability, распределенное хранение и т.д. И эти ораклы с постгресами с ними просто не способны конкурировать по надежности и скорости работы. Все эти крутые спринги, ораклы и хайбернейты это наследие уходящей эпохи монолита. Эпоха микросервисов и облачных функций это быстрый старт приложений при возникновении нагрузки, отсутствие состояний для высокой масштабируемости и безжалостная выгрузка всех приложений и ресурсов, которые в данный момент не нужны и лишь бессмысленно расходуют оперативную память.

Заключение.


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


Подробнее..

От Junior до Team Lead за 3 года

02.07.2020 18:23:23 | Автор: admin

Hello, world


Я DevOps-инженер, и я не существую.

Я не существую!?

Потому что DevOps это методология или философия, но никак не специальность. Однако всем в ИТ привычнее закрыть на это глаза и считать, что единороги существуют. Не буду рушить эту по-детски милую и наивную рекрутерскую иллюзию. В компании, в которой я работаю, моя позиция называется Configuration Manager или Инженер Конфигурации Программного Обеспечения. Я думаю, что понятнее вам не стало, да? Окей, давайте по порядку.

Что такое DevOps?


Давайте быстрее, я здесь не молодею

Development+Operations=DevOps

Это если коротко.

Если хрестоматийно, то DevOps это про коммуникации между Разработчиками и Отделом Эксплуатации на проекте. Если девелоперы создают код, не заботясь о его судьбе на стадии эксплуатации, то в проекте нет DevOps.

На деле понятие DevOps ещё шире. Devops это о поставке качественного кода в короткие сроки с использованием для этого доверительных коммуникаций, чётко описанных процессов и автоматизации. Во имя конечного потребителя и прибыли компании, конечно же.

Поэтому взять и выделить DevOps-специалиста с набором обязанностей для достижения Reduce time to market невозможно. Это коллективная работа. Так что чаще всего под DevOps-инженером понимают человека, который делает автоматизацию на проекте, настраивает окружения и мониторинг. Большим плюсом будет, если он будет читать проповеди о культуре взаимодействия, способствовать архитектурным и ретроспективным встречам между разработчиками и отделом эксплуатации. В общем, выступать DevOps-евангелистом.

http://personeltest.ru/away/devopstopologies.ru
devopstopologies.ru

В Романе The Phoenix Project легко и увлекательно рассказывается про этот наш DevOps. Прочёл на одном дыхании.

Начало пути


В ноябре 2016 года я проходил оплачиваемую стажировку в компании ИТСК на позиции Младшего ИТ-Архитектора. В декабре заканчивался 6-месячный срок, после которого меня должны были принять на постоянной основе. Однако за пару месяцев до этого мне сказали:
Если хочешь дальше работать ИТ-архитектором, то нужно иметь 1-2 года опыта работы разработчиком.

Абсолютно адекватное требование. Я бы даже сказал, лет 5 не помешает, но на тот момент я не знал об этом. Я учился на разработчика, и это не вызывало во мне энтузиазма, так что я не искал подобные позиции. И потому предложение пойти писать код, а потом возвращаться, меня не вдохновило. Забавно, конечно, что узнал я о требовании руководства на 5-м из 6-ти месяцев оплачиваемой стажировки.

Я начал подумывать переступить через своё не хочу и устроиться разработчиком, как до меня дошло спросить у друга Серёги, DevOps-инженера:

Я: Серёга, а что ты делаешь на работе?
СЕРЁГА (DEVOPS-ИНЖЕНЕР): Ну там, это.

Бинго! Это же то, что мне нужно. Не разработка, но ИТ, а значит, я в этом что-то понимаю или научусь понимать, я же сам себе ПК собрал. Главное не писать код, упаси C#. Сергей как раз менял место работы в декабре и порекомендовал меня на замену, но даже не позвонили. Тогда я начал самостоятельный поиск.

***

В январе пошёл снег, а я на первый собес, где мне отказали из-за слабого английского. Тогда Серёга снова порекомендовал меня, но на новом месте работы. Меня не стали рассматривать из-за отсутствия опыта. Потом ещё собес с отказом. И тут мне крайне повезло, что есть такая компания, как EPAM с вечерней DevOps-школой и трудоустройством по окончанию обучения. Это большая интернациональная компания, работы в которой навалом, а специалистов конфигурации ПО с мышлением DevOps в то время было ещё меньше чем сейчас. Возможно, что они первые в России открыли подобные курсы, тем более бесплатные.

В феврале прошёл отбор, и в конце месяца началось обучение. Занимались трижды в неделю по вечерам. Отбор в школу прошли 20 человек. ~15 были со стороны, а остальные уже работали в компании. Заявок всего было ~120. Подготовиться к отбору мне помогли курсы по Linux, DB и Python на степике и, конечно же, бакалавриат в ИТМО. А ещё Серёга учил меня, как работать в Jenkins, и вселил уверенность в свои силы.

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

Резюме




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

***

В марте я продолжил ходить на собесы, поскольку повышенной стипендии в 7 тыс на жизнь в 2017 году не хватало, и мне даже пришлось занимать деньги на еду и оплату общежития.
Мне не перезванивали, что явно не красит лицо знаменитых компаний, куда я приходил, но зла держать нет смысла. Просто будьте готовы проявить инициативу и спросить.

Так и запишем

И вот в мае Серёга, который тоже не сдавался (потому что я у него занимал деньги), в третий раз порекомендовал меня. В этот раз на новую позицию в T-Systems, где были готовы взять и обучить джуна, который понимает основы. А благодаря школе EPAM я получил нужный базис. Чутка успел подкачать английский, который всё равно был ужасен, но собеседовавший меня мой будущий People Manager, стиснув извилины, смог понять, что же я там плету, вставляя герундий туда, куда приличные люди не вставляют. Спасибо, Илья, что поверил в мой лингвистический и технический потенциал.

Забавно, что в день собеса мой будущий тимлид был в отпуске и ему меня сосватали не глядя.

Иван Степаныч радуется
Иван Степаныч радуется

Junior DevOps


17 мая 2017 года мой первый рабочий день джуном. В команде я и тимлид. Через месяц приняли в команду третьего. Потом разрослись до 6 человек через год.

О, это потрясающая пора в жизни каждого начинающего специалиста: впитываешь знания взахлёб, тупишь над простыми задачами, читаешь сложные книги, гуглишь детские ошибки. Хотя и сейчас точно также гуглю, ничего не изменилось.

Вот базис начинающего специалиста: Jenkins, Linux Administration, Bash, Git. Потом желательно Docker, Kubernetes и/или OpenShift, Ansible, Python.

Само собой, знать сразу всё невозможно. Например, Docker мне на начальных этапах не был нужен, но понимание концепции от меня ожидали и спрашивали на собеседовании. Да и никто не говорит о глубоком опыте в Linux или, о ужас, попросить установить и настроить Jenkins. Так, уметь тыкать в интерфейс, понимать, как его можно использовать в первом приближении. Обучаешься в процессе решения рабочих задач.

А чем старше проект, тем меньше в нём того, что в желательной части и больше Bash. Всё обмотать длинными спагетти Bash-кода излюбленная автоматизация столь близкого нам прошлого. Как говорится: Знаешь Bash? Тогда Иди работай!.

I'll be bash

Конечно, в мире ИТ каждому инструменту есть альтернатива и не одна. Так что единого стека технологий даже в рамках одной компании не бывает, хотя и стараются. Подготовиться к определённому стеку технологий можно месяца за два неспешного изучения раза 2 в неделю. Ко всему месяца за четыре раза 3 в неделю.

В период джуновства большая часть задач относилась к изучению и применению команд в Linux и написанию Bash-скриптов. Ещё лично мне перепала возможность проявить себя как веб-разработчик и создать сайт для отображения информации по хостам. Специфичная для проекта штука. Скринов старой версии у меня нет, так что держите новую версию, полностью переписанную позже моим коллегой.

Dashboard

Здесь пригодился опыт в HTML, CSS, JavaScript, Python. Но если бы не умел, то и не стал бы делать. Так что на заметку можно взять только Python.

Middle DevOps


Прошло 10 месяцев, и меня повысили до просто инженера. Здесь важно понимать, что в каждой компании своё понимание того кто такой Junior (младший), Middle (средний) и Senior (старший). И разные зарплатные вилки на позиции. Слышал как-то, что в некую компанию взяли парня джуном за зарплату сеньора. Я понятия не имею, правда ли это, но не исключаю подобного.

Так вот, ведущий эксперт в одной компании может запросто стать мидлом в другой с понижением зарплаты. А вот это уже реальный кейс информация проверена. Происходит так, потому что стек знаний и инструментов разный. А ещё задачи разные. Это если ты Java-программист, то в любой компании будешь писать код. А если ты DevOps-инженер, то под табличкой может скрываться от разработчика, до специалиста службы эксплуатации.

Отдел эксплуатации
Как себе представляет специалиста эксплуатации гуманитарий. P.S. Гуманитарии, я вас люблю

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

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

Шучу.

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

Senior DevOps


Через год, а именно в апреле 2019 года, я повысился до сеньора-помидора. Как говорится: хочу салат не вижу препятствий. Ещё говорят, что с большой силой приходит большая ответственность. Вообще, справедливо. Только в профессиональной стезе наоборот: сначала ответственность, а потом подтягивается сила и уверенность. То есть сначала нужно иметь смелость замахнуться на слона и уже потом, на пути, дорасти до его ушей.

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

С одной стороны, это этап прокачки вглубь, с другой стороны, так как я стал сеньором уже через два года работы, то мне ещё расширяться и расширяться. Правильнее судить годами. Так вот прокачка вглубь идёт где-то после лет 3-5, если стек не меняется.

Но мир IT изменчивый: сегодня ты пишешь код на Python, а завтра от соискателей требуют прогрессивный Go, поэтому глубинная прокачка всегда сменяется изучением новых инструментов.

Однако побыть сеньором мне не дали

В начале мая мой тимлид сказал, что уходит из проекта. А так как я с самого начала карьеры показывал своё желание расти до менеджерских функций, то мне предложили стать тимлидом. Конечно, я знал проект лучше всех, но молоко на губах ещё дрожало, и в проекте были коллеги с гораздо большим опытом, чем у меня. Однако, назвался груздём становись грибом. Так что я стал. Раньше, чем планировал.

Это Гарольд нашёл меня
Это Гарольд нашёл меня

Вы ожидаете, что здесь будет раздел с названием Team Lead DevOps? А нет, повышение так не работает. Повышают не чаще раза в 9 месяцев, но это в моей компании. Где-то повышают раз в полгода, где-то в год. А вообще, спланировать график повышения невозможно наверняка, так как он зависит от твоих успехов и чуткости руководителей. Можно и за два года не получить повышение.

Однако функции тимлида пришлось выполнять уже сейчас. Первые 3-4 месяца было особенно напряжно и непривычно. Куча коммуникаций. Множество задач у всей команды, в которых нужно ориентироваться. Постоянно приходят тестеры и разработчики и что-то спрашивают или просят сделать. А так как на мне большая база знаний, то делегировать без обучения не получается. Написанные инструкции ситуацию не спасают. Среди более опытных коллег ощущаешь себя не на своём месте. Вместе с этим появляются новые микросервисы, где нужна наша помощь. В общем, потно-плотно.

***

В октябре 2019 поехали в Германию, чтобы встретиться с коллегами из Польши и Немеции. Да, я взял на себя роль тимлида, но только лишь питерской команды. Ещё по двое коллег были из этих стран. И формально, тимлид всей команды был в Германии. К сожалению, по большей части формально.

В октябре мы поняли, какой жуткий рассинхрон у нас произошёл.

Несмотря на созвоны трижды в неделю и периодические командировки, у нас не было общего мнения по одному важному вопросу. Связывали мы это на питерской стороне с тем, что коммуникации на английском языке мешают нормально объясняться, плюс сопротивление предложению со стороны иностранных коллег. В итоге на создание демо было потрачено 6 месяцев одним человеком. И после показа решение забраковали. Потому что на такие изменения команда эксплуатации не готова, ведь мы только 6 месяцев как внедрили новый подход.

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

В команде из 10 человек задача более-менее посильная, но усложнённая языковым барьером и расстоянием между всеми. Да и не только ведь этим приходится заниматься.

***

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

Пары, вставай

Так вышло, что он не был DevOps специалистом изначально в проекте. Он начал как разработчик и затем постепенно перешёл в Инженеры Конфигурации ПО. И, вероятно, неожиданно сам для себя стал тимлидом в 2017 году. Так что выбрать DevOps-школу было верным для него решением.

Однако тогда я думал, что причиной послужила ситуация на проекте

***

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

С ноября я начал замещать тимлида. Пытался придерживаться свежесозданной дорожной карты. Пытался, потому что точного понимания происходящего у меня не было. В создании карты участия я не принимал. А когда её презентовал тимлид, то я не понимал как её можно улучшить и правильно использовать. Однако, имея план, руководить проще, чем не имея.

Новые обязанности выполнял я, откровенно говоря, не очень. Только отошёл от шока тимлидства в Санкт-Петербурге, как теперь ещё плюс две локации. К тому же полноценным руководителем я себя не ощущал: функции тимлида нигде не описаны, примера для подражания не было. На что опираться?

Поэтому как я могу руководить всеми? Да ещё более опытными иностранными коллегами. К своим я постепенно привык и освоился, а тут новая партия подъехала. И ладно бы партия стандартного калибра, так ведь один из снарядов такой бронебойной силы, что чуть отвернёшься, а у тебя чат 30-ю сообщениями завален от него и новая Bash-портянка готова. Bash это хорошо, Bash это здорово. Однако нужно понимать, когда нужно использовать Bash, а когда другой язык или инструмент.

***

В январе 2020 приехало повышение за июнь. Снова ожидаете Team Lead DevOps заголовка? А не будет его. Тимлид это роль, а не должность. Так что вряд ли вам напишут в трудовую книжку руководительский подвиг в технической команде. Вам нужно в Project Manager'ы для этого идти.

Получается, что тимлидом может быть и джун. А меня повысили до

Expert DevOps


Январь и февраль прошли. Вернулся немецкий тимлид. Наконец-то! , подумал я. За это время у меня сложилась картина, что нужно делать, чтобы повысить нашу эффективность: как правильно создавать дорожную карту, распределять задачи, выстраивать коммуникации, обсуждать, проверять чужие решения.

А я уже представляю, как всё это ему рассказываю. Как он кивает головой, говорит: Sure, и вокруг нас расцветает малина.

Но нифига.

Вернувшись в проект, тимлид не забирает на себя свои обязанности, типа проведение созвона для сбора статуса. Не интересуется задачами коллег. Не инициирует беседу, если видит что-то непонятное для себя. Ведет себя абсолютно пассивно. Я понимаю: первую неделю или две, но ведь уже апрель.

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

И под конец апреля выясняется, что текущий тимлид ещё зимой принял решение уйти в другой проект, где проходил практику от DevOps-школы. Только теперь на позицию специалиста эксплуатации.

Тут мне стало понятно почему он так легко отнёсся к отжиму обязанностей с моей стороны.

Наши дни


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

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

Каковы мои дальнейшие возможности? Их несколько.

  1. Ничего не менять с точки зрения позиции. Продолжать лидить, параллельно изучая новые инструменты и углубляя знания. Рано или поздно дойти до позиции архитектора по DevOps профилю.
  2. Перейти в другую команду и снять с себя роль тимлида. Сосредоточиться на изучении новых инструментов и прокачиваться как инженер. Рано или поздно дойти до позиции архитектора по DevOps профилю и роли тимлида.
  3. Пойти в менеджерскую ветку. Мне предлагали рассмотреть роль Scrum-мастера. Неожиданно, правда? Однако сейчас такой возможности уже нет, ввиду организационной трансформации в компании в матричную структуру. Вообще, это не единственный способ перейти в менеджмент в T-Systems, однако подробности за рамками этой статьи.

Позиция руководителя мне привычна и вызывает больший отклик. Тактики, стратегии, психология и социология one love. Однако здесь важно быть увлечённым проектом/продуктом. Что для меня задача не из простых. Чтобы вы понимали что я за человек: я мог бы открыть точки продажи кофе, пиццерии, производство пластиковых упаковок, свою криптобиржу, однако я не хочу делать то, что или деструктивно, или вредно, или бесполезно. Даже если это окупается моментально или приносит сверхприбыли.

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

Так что или 1-ый или 2-ой вариант. Желаю себе успехов на одном из них!

Ты красавчик!

Послесловие и благодарности


Вообще, я бы хотел стать знаменитым певцом

Directed by
*Играет музыка*

Ну что поделать всему своё время. Сначала научусь петь.

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

Кстати, есть ещё одна возможность стать DevOps-инженером быстро и безболезненно.

В сентябре планируем открыть набор в DevOps-школу в T-Systems. Точнее будет понятно в начале или середине августа. Участие бесплатное и с трудоустройством после успешного завершения. Из требований: Linux на уровне пользователя и английский. В программу обучения входят упомянутые и неупомянутые в статье инструменты: Kubernetes, OpenShift, Jenkins, GitLab, Ansible, стек для мониторинга и ещё немного других полезностей.

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

За мой карьерный путь, наставничество и чуткость руководства благодарю моего бывшего тимлида питерской команды Сергея Жекписова (я капец как многому у тебя научился!), моего пипл менеджера Илью Семерханова, руководителя направления Дмитрия Жаркова и моих коллег, когда-либо работавших вместе со мной.

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

Большое спасибо Иномджону Мирджамолову за первое прочтение и предложенные правки в данной статье, а также отделу коммуникаций T-Systems.

Моя текущая команда, вы суперские, мужики! Жму ваши виртуальные руки.
Подробнее..

Из песочницы Что делать, если в вашей команде появился эффективный менеджер?

02.07.2020 18:23:23 | Автор: admin

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


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



Дано: продуктовая команда удаленщиков с почасовой ставкой, выстроенными и отработанными процессами пятый месяц работает над MVP мобильного приложения в сфере geo-dating. Работа движется по плану, в соответствии с согласованными требованиями, с еженедельными демо-показами без критических отставаний по срокам. Команда сильная, все ребята из топовых IT-компаний. Координатор со стороны инвестора, не технический человек, помогает нам в административных делах и коммуникацией с инвестором. Я выступаю в роли проджект/продакт менеджера, отвечаю за реализацию продукта, его качество и соответствие ожиданиям инвестора. Казалось бы, все более-менее идеально, через месяц должен быть первый публичный релиз.


Вводная: инвестор, пообщавшись с друзьями из мира IT, слышит следующий тезис: Твоя команда из тебя деньги вымогает. Да твое приложение можно было за 3 месяца выпустить за те же деньги. Давай я тебе покажу как надо! Я их выведу на чистую воду!.


Результат: к нам приходит человек, который 10 лет занимается автоматизацией бизнес-процессов стекольной компании на базе платформы 1С, проводить аудит нашей работы и внедрять эффективность в командные процессы. Надо сказать, что не один, а взяв с собой Agile-коуча и технического специалиста из своего окружения.


В итоге, вместо месяца до релиза MVP внедрение эффективных менеджеров, стоило компании половины продуктовой команды, увеличение сроков выпуска продукта еще на полгода и увеличение ежемесячных расходов ровно в 2 раза!


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



Шаг 1. Внутреннее умиротворение


Если вы попали в такую ситуацию, первое, что нужно сделать, перестать нервничать как можно раньше.


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


Спустя год, я могу дать такой совет. Но на тот момент и я, и команда очень болезненно переживали процесс внедрения эффективных менеджеров, вплоть до нервных срывов. Помню был солнечный субботний летний день, я встретилась с нашим координатором от инвестора насчет мелких административных вопросов, и в конце встречи она сказала очень правильную фразу, которую я стараюсь больше не забывать: Я вижу, как все переживают за судьбу продукта и его успех, проделано уже очень много работы, но не принимайте все так близко к сердцу, дураков много, а специалистов единицы.
Теперь можем переходить к шагу 2.


Шаг 2. Принятие


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


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


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


Шаг 3. Сохранение целостности команды и ограждение от деструктивного воздействия


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


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


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


Шаг 4. Обеспечение максимальной открытости и доброжелательности к новоприбывшим


Как я уже упомянула в шаге 2, нет смысла противостоять ситуации, она уже случилась. Уже все решено. Ваша задача сократить потери и выжать максимальную пользу.


Новые руководители хотят аудит? Хорошо, собираемся на общую встречу. Показываем все ресурсы, рассказываем про все технологии, как устроена инфраструктура, как работают сервисы, по каким методологиям работаем, как выстроены процессы вплоть до перетаскивания задач в таск-трекере; показываем бэклог и описываем работу с ним. Это будет долгое и изнуряющее мероприятие, порой будет казаться, что немного унизительное, но через это стоит пройти.


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


У нас такая сессия заняла 3 часа. Была перевернута вся документация, проверены все метрики, просмотрена каждая функция приложения. Под конец встречи наши новые руководители не знали, к чему придраться и признали, что вся работа ведется на должном уровне (хотя многих слов в объяснениях даже не поняли), однако заявили, что смогут усилить нашу команду и сделать продукт еще прекраснее.


Шаг 5. Утверждение обязанностей


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


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


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


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


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


Шаг 6. Интеграция в процессы


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


Особенно это классно срабатывает с теоретиками, которые съездили на какой-нибудь тренинг или сертифицикацию и точно знают, как надо по методичке, а если что-то не так как там, то неправильно.


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


Шаг 7. Определение канала влияния


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


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


Шаг 8. Переход к совместной работе


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


Ни для кого не секрет, что вся инфраструктура регистрируется на определенные аккаунты и их смена часто бывает очень муторной. Для крупных компаний сейчас прозвучит очевидная вещь, а малый бизнес очень часто этим грешит. Никогда, пожалуйста, никогда ничего не регистрируйте на частные аккаунты сотрудников. Только на компанию или, максимум, на основателя. У нас часть была зарегистрирована на ООО, часть на тим лида. И, конечно, первое, что решил сделать эффективный руководитель перерегистрировать все на себя. Без комментариев. Аргументация так я смогу вовремя проводить оплаты и контролировать все доступы. Помним, что у инвестора полное доверие к этому человеку, а команда все еще обманщики.


Тут нас ждали первые потери со стороны команды: ушли люди, которые не захотели участвовать в этом цирке. Их можно понять. Но проблема состояла в том, что ушли все back-end разработчики. Причем уволили их одним днем за проявление неуважения к новому руководителю, о чем я писала выше.


Таким образом, мы остаемся с минимальной документацией по инфраструктуре и без переданных дел. Эффективно, не правда ли?


Я с остатками команды выделила задачи, которые можно делать без back-enda. Благо, они обгоняли клиентскую часть по решаемым задачам.


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


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



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


Эту работу я взяла на себя. Хорошо, что все ведется в таск-трекере и настроить выгрузку отчетов было несложно. До этого мы просто не тратили время команды на отчетность, так как таск-трекер доступен всем, и информацию о проделанной работе можно узнать в любой момент времени.
Здесь эффективные менеджеры первый раз выстрелили себе в коленную чашечку. На шаге 6 мы установили, что все равны перед процессами. Соответственно, если команда должна подавать детальные отчеты о своей деятельности, то и они тоже. Тут пришло осознание, что у нас отсидеться на фиксированной зарплате, ничего не делая, не получится.


Таким образом, задачи на новоприбывших в таск-трекер ставятся, результатов нет, отчеты выгружаются с нулями. Это видит координатор. На что приходит парирование: Мы будем подавать свои отчеты и готовить их отдельно. Хорошо, работаем дальше.


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


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


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



Шаг 9. Работа над продуктом


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


Итак, когда были восполнены ресурсы команды, внимание эффективных менеджеров сразу же переключилось на продукт. Посыпались требования, что нужно доработать еще вот это и вот это, и еще много-много функций. Если на ваш аргумент, что предлагаемые гипотезы требуют проверки, вы слышите: это очевидно и утверждено с инвестором, то спокойно дополняйте бэклог. Но если есть возможность, то лучше уточнить у инвестора по другому каналу, утверждены ли изменения. К сожалению, у нас такой возможности не было, координатор уехала в длительную командировку, и уже не могла уделять время нашему направлению. Можно сказать, что так мы остались с эффективными менеджерами один на один. И вот эта мнимая очевидность и согласованность требований, в связке с незнанием продуктовых процессов, оказались фатальными и стали началом конца для карьеры руководства в нашей компании.


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


Шаг 10. Подведение итогов


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


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


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


Каково же было удивление инвестора, когда через полгода работы он увидел намного меньше, чем ожидал, по своему вектору развития и увидел, то о чем даже не догадывался. Хотя, надо сказать, что команде удалось за это время реализовать ряд полезных улучшений для продукта, которые мы смогли защитить у эффективных менеджеров, а затем объяснить ценность инвестору.


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


Выводы


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


И, конечно, честность перед командой, честность перед инвестором ключевые моменты при построении рабочего процесса.


Безвыходных ситуаций нет, есть тернистые пути, которые приходится проходить.


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


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

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

Подробнее..

Игровая механика для скрам-команды, которая любит настолки

03.07.2020 14:20:11 | Автор: admin
Мы в команде обожаем настолки. И чем сложнее их механика, тем интереснее.

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

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



Привет! Меня зовут Павел, я занимаюсь фронтендом и скрамом в команде Wrike. Мы работаем по Scrum, сейчас у нас около 30 команд, в одной из которых я скрам-мастер. Я им стал уже больше года назад и хочу поделиться своим опытом, как мы пытались геймифицировать наши процессы.

Что для нас означают командные бест-практики


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

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

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


Команда, когда я прошу ее помнить про договоренности с ретро

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

Набор карт и правила


У нас было несколько групп ситуаций: флоу разработки, продуктовая проработка, общие процессы и т.д. Мы разбились на 3 группы и после брейншторма получили вот это:

Проклятие: Соплежуй
Разыграй эту карту на больного человека. Немедленно отправь его домой.

Проклятие: Покорми QA
Отдай тому, кто не прогнал автотесты по своей ветке перед передачей в тестирование.

и еще одна про то же самое:
Ассенизатор
Разыграй эту карту на того, кто передал ветку QA, не запустив автотесты. Несчастный сам разбирает упавшие автотесты.

как в самом Манчкине:
Гадкая парочка
Отдай эту карту QA, если хочешь, чтобы твою ветку заранее потестировали параллельно с ревью.

Проклятие: Фиксик
Сыграй эту карту на игрока, чья ветка развалилась на спринт ревью. Выбранный игрок проводит следующее спринт ревью вне очереди.

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

Проклятие: Скорострел
Отдай тому, кто перевёл таску в тестирование до окончания ревью. Игрок должен выполнить сокровенное желание QA.

Проклятие: Невероятно грязное ругательство
Разыграй во время любого митинга. Тот, кто залипает в ноут, закрывает его и кладет на свой стол.

Гонг
Разыграй эту карту после дейли. Вся команда встает и идет на обед.

Шмотка: Арбалет поражения ложных тепловых целей
Используй, когда кто-то меняет план спринта. Игрок с арбалетом должен актуализировать цели спринта.

Броник: Худи-неведимка
Можешь заливать технические итерации в мастер в скрытом виде, если они не будут доступны пользователям.

Бросить перчатку
Немедленно призови скрам-мастера и лида, если чувствуешь, что занимаешься чужой работой (например, другой команды).

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

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

Черная дыра
Играй, если PO передал dev-команде не готовую к проработке историю. Команду засосет черная дыра, а история вернется к PO или UX.

Грязевой ком
Играй для растянувшейся задачи, если никто заранее об этом не подсветил это на дейли. Провинившийся игрок проводит следующее дейли.

Проклятие: Полиамория
Играй в пару FE и BE, чтобы они начинали интегрироваться (можно безопасно на заглушках).

Подкупи стейкхолдеров
Можешь не рассказывать о фейлах на спринт-ревью.

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

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

Правила игры

  1. Участвует вся команда (как минимум 1 экспериментальный спринт).
  2. Карта может быть разыграна в любой момент, то, что на ней написано обязательно к выполнению.
  3. Чтобы разыграть карту, нужно публично выложить ее на стол во время митинга, объявить об этом во время дейли или отдать другому игроку.
  4. Карты раздаются рандомно.

Раздаем карты


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



Первое, что мы заметили она началась достаточно вяло. Самые интересные карты были связаны с активной фазой спринта, когда задачи растягиваются, переходят от разработчиков к QA или деплоятся. В первый день ребята только создавали ветки и вникали в требования. Никаких триггеров еще не произошло, поэтому сыграли только технические карты: например, Гонг, чтобы всем вместе пойти на обед.

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

Мы сыграли Гадкую парочку, когда дело дошло до ревью одной из задач. Логика оказалась достаточно сложной, был смысл проверить ее заранее параллельно с ревью, тем более у QA было свободное время. Кое-кто забыл прогнать автотесты перед тем, как отдавать задачу в тестирование пришлось покормить QA обедом. Ближе к концу спринта я разыграл на себя Соплежуя и поехал домой, чтобы не сидеть и не кашлять в общей комнате.

При этом большую часть карт разыграть не удалось. Первая проблема была в том, что мы раздавали их рандомно. Кажется, по аналогии с Манчкином стоило добавить классы Фронтендер, Бэкендер, QA. Если бы на Ассенизаторе было написано Только для QA, он бы попал к ребятам, которые в нем заинтересованы. К тому же все случаи с не запущенными автотестами точно пройдут через них, а разработчики с такой картой на руках могли про них даже и не знать.

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

Какой вывод мы сделали


Как минимум, это весело! Было интересно всем вместе придумывать механику, особенно в таком стебном стиле. И оказалось интересно попробовать, как она работает.

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

Идея с геймификацией команде зашла, но ее нужно тюнить. Стоит отказаться от случайной раздачи карт, ввести классы и классовые ограничения для карт (Только для QA), подумать над механизмом обмена и обновить список триггеров (чтобы там оставались только актуальные проблемы).

Какую карту вы бы разыграли сейчас? Что добавила бы ваша команда?
Подробнее..

Эх, айти, куда ж ты котишься?

04.07.2020 14:10:42 | Автор: admin
Ну что, Хабр, прошло полгода какого-то очень неприятного 2020, до конца десятилетия ещё чуть-чуть и уже сегодня я могу сказать: это десятилетие прежде всего стало золотым веком IT-сферы. Накопленный опыт, новые эксперименты и крутое железо сделали своё дело. Казалось, что айти стало новым рок-н-роллом, но как-то быстро оно приблизилось к тому, чтобы стать новой попсой. Все хотят в айти, неважно кем: менеджерами всего и по всему, переводчиками, деврелами, пиарщиками, копирайтерами, ну и собственно программистами, тестировщиками, инженерами. А отрасль тем временем сильно видоизменяется. Предлагаю вам поговорить о нас, о нашем айти и о том, куда всё катится.


Сразу предупрежу: статья эмоциональная, противоречивая и очень субъективная взгляд одного человека, который в отрасли всего 11 лет и попал в волны её эволюции. Сложно структурировать такой текст, но я всё же постараюсь.

Глава 1. Программисты


Культ программирования


Программисты это космонавты нашего времени, ими хотят стать буквально все: профессия кажется модной, перспективной и высокооплачиваемой. Самое интересное, что культ распространяется не только на школьников, студентов и их родителей, но и на компании. Года так с 2015-го формируется интересное поветрие: все компании стремятся назвать себя ИТ-компанией. Банки, ритейл, интернет-магазины и даже пиццерии позиционируют себя именно как технологические. Здесь происходит подмена понятий: если компания вооружилась крутыми технологиями и предоставляет технологичные услуги своим клиентам, это не ИТ-компания, а продвинутые в плане технической трансформации банки, ритейлеры, рестораны и т.д. ИТ-компания это всё же те организации, которые разрабатывают, внедряют, развивают и поддерживают технологии: хостинги, ЦОДы, разработчики ПО, производители железа, системные интеграторы и т.д.

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

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

  • Веб-разработчики всех мастей, которые делают сайты на коленке и на популярных CMS и даже умеют сотворить CRM на заказ за месяц. Понятно, что здесь не идёт речи ни о качестве, ни о кастомизации, а сами ребята не знают ни алгоритмов, ни правил рефакторинга, ни паттернов и лучших практик говнокодят от души, и всё. Опасная группа, так как с ними небольшие компании часто влетают на деньги и, обжегшись на молоке, дуют и на воду перестают доверять ИТ-отрасли в принципе, начинают отрицать автоматизацию.
  • Следующая группа очень безобидная это мечтающие питонисты. Python покорил мир не хуже, чем котики и в итоге его понемногу учат аналитики, переводчики и даже политологи, чтобы с возрастом уйти в дата сайнс. Понятное дело, что всё учение чаще всего сводится к чтению Лутца и просмотру онлайн-курсов, никакой практики и даже претензий на стажерство. Отдельные маргиналы отвергают Python и учат JavaScript, потому что он простенький и понятный (в этом месте у нормальных разработчиков сводит скулы и выступает пот).
  • Просто образованцы, которым всё равно что учить в текущий момент времени сейчас мода на программирование, значит, программирование. Программисты из них получаются редко, а вот достойные тестировщики встречаются.

Образованцы и образованные


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

  • Классическое техническое образование в вузах пока держится и даёт хорошую основу для дальнейшей инженерной и разработческой карьеры. В последнее время всё чаще к преподаванию привлекаются практики из компаний, да и сами компании создают свои кафедры, школы на базе вузов, курируют направления. Появляются гибридные направления вроде инфобезопасности, компьютерной лингвистики, биотеха и медтеха, и это весьма перспективные специализации. Из недостатков по-прежнему большое количество преподавателей, которые дают устаревшую, а иногда и неверную информацию и общие предметы из образовательного стандарта, которые не дают ровным счётом ничего (даже обычную эрудицию!), но отнимают часы от профиля.


  • Заменители технического образования (прикладная информатика, бизнес-информатика и т.д.) слабые факультеты в нетехнических вузах, которые открываются для целей набора большого количества студентов, не прошедших в профильные. Образование в большинстве случаев откровенно слабое, преподаватели предлагают устаревшие программы. Исключений мало, правда, они есть.
  • Корпоративные университеты и курсы направление, которое в последнее время ощутимо выросло в качестве и подходах (появились бесплатные слоты, узкие и комплексные программы по разработке и менеджменту, встречаются даже программы для детей). Преподают сами сотрудники, поэтому максимум практики, минимум болтовни. Ощутимых недостатков два: 1) компания обучает под свои требования и шаблоны; 2) такое образование не может заменить высшее и подходит для начинающих готовых специалистов. По сути это исключительно дополнительное образование.
  • Комплексные коммерческие университеты слабые учреждения для понтов и сбора денег. Без комментариев. Но народ идёт, потому что доступно и иллюзорно просто (читай ни о чём).
  • Онлайн-курсы, школы, университеты колоссальная часть индустрии, которая выглядит как джентльмен во фраке, который три месяца не мылся. Вроде и прилично, но при ближайшем знакомстве чёрт побери! Да, хорошие и даже именитые преподаватели, внятные и поэтапные программы, но это низкий уровень подготовки, не соизмеримый с потраченными деньгами. Это же время лучше потратить на просмотр курсов MIT и активное самообучение.

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

Зарплатный коллайдер


Заплаты на ИТ-рынке перегретые во многом из-за того, что компании не-айтишной сферы имеют ресурсы, чтобы устраивать гонку за разработчиками. Условный банк готов заплатить за готового бэкенд-программиста гораздо больше, чем условный поисковик или разработчик ПО, который предпочтёт вырастить себе разработчика из junior-а. Ещё больше платят проектные компании и аутсорсинговые компании (особенно зарубежные). Программисты ощущают себя новыми рок-звёздами, и вот уже сопляк выпускник после окончания мехмата с опытом тестирования 0,5 года закидывает ногу на ногу и требует соточку чистыми.

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

Немалую роль играет и доступность удалённой разработки: зачем ходить в офис, коммуницировать, наращивать скиллы, если можно кодить от сих до сих удалённо для столичной компании, которой 100 тыс. не вопрос. При этом значительная часть разработчиков добровольно попадает в ловушку с низким потолком: создавая код и получая достаточную сумму сейчас, они не развиваются вне компании, не формируют навыки проектирования ПО, так и остаются специалистами, способными быстро писать хороший код. Рано или поздно наступает их персональный потолок, и чтобы его пробить, нужно менять работу и нередко уходить на более низкую заработную плату. Та же проблема возникает и с некоторыми системными администраторами DevOps и облачные технологии вместе с невероятными возможностями удалёнки принесли ситуации перегрева и потолка.

Чёрные дыры IT-мира


Среди настоящих ИТ-компаний есть чёрные дыры они собирают к себе всех более или менее толковых разработчиков, предлагая хорошую заработную плату и условия. Однако это, как правило, большие компании, которые занимаются проектной заказной разработкой и в любой момент возвращают на рынок труда не только отдельных специалистов, но и целые команды. Именно они во многом причастны к созданию упомянутого зарплатного коллайдера.

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

Интроверт, характер мерзический


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

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

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


А вы знаете ответы на эти вопросы? Народ хочет знать :-)

Глава 2. Деловое окружение


Охотники за головами


Конечно, на поле боя за айтишников важная роль отводится HR-специалистам, которые уже давно переросли стандартную должность кадровика и превратились в HR, специалистов по развитию персонала, DevRel (специалистов по связям с разработчиками и внутреннему HR PR) и проч. В некоторых компаниях даже есть отдельные HR для найма в R&D и отдельные для всего остального. Они не брезгуют никакими средствами, лишь бы добиться своего и заполучить специалиста, но нередко губят своё же дело на собеседованиях (просьбами написать код на листочке, speak in english with me, вопросами из первых позиций выдачи гугла и психологическими задачками).

Найм ведётся на конференциях и митапах (а вы думаете, для чего они устраиваются?), в закрытых чатах, в сообществах в социальных сетях, на специализированных сайтах и т.д. Так что если вы ищете работу и вдруг внезапно вас зазвонили со всех сторон, знайте вероятно вас трудоустраивает ваш же HR. Стоит вам устроиться в компанию (особенно в крупную), вас тут же окружает заботой и вниманием не наставник, который необходим для успешного старта, а специалист по внутреннему PR, который проводит по офису, показывает вазочки с конфетками и фруктами, дарит тапочки и обращает внимание, что вышитый или нанесённый на них логотип компании как бы намекает о причастности к великому.

Они почему-то не понимают, что основной стресс нового сотрудника происходит нет от неудобных тапочек или грустных рыбок в аквариуме, а от сложности вхождения в рабочий процесс, в правила разработки, code style, особенности проектов и т.д. В employee orientation (информирование новичка) должно входить прежде всего ознакомление с обязанностями, функциональными особенностями должности, с сотрудниками команды (в первую очередь связанными с рабочими задачами). И на первом этапе самый ценный человек не формальный, а включённый коллега-наставник по профильной деятельности, который всё объяснит, всему обучит, разъяснит и безболезненно включит в разработку. А тапочки и из ИКЕИ сойдут.

Вообще офисы это отдельная история. Компании стремятся строить какие-то невероятные корпоративные диснейленды со спортзалами и проч., лишь бы сотруднику хотелось находиться в офисе как можно дольше и держаться за обстановку. Однако, например, в трёх очень крупных компаниях я видел всё что угодно, включая капсулы для сна и массажные кресла в SPA-комнатах, но при этом в компании очень ограничено медицинское обслуживание как в плане ДМС, так и в плане внутрикорпоративной медицинской помощи. То есть в офисе на 4 этажа сотрудники не могут рассчитывать на оперативную помощь вопросы экстренных проблем со здоровьем решает скорая. И да, многие ребята говорят, что им жалко расставаться с удобством, поэтому они не переходят в более интересный проект на более интересные деньги.

Отдельным отрядом за ИТ-специалистами охотятся кадровые агентства, которые умеют продать своим клиентам не очень качественного работника как супер senior-а. В принципе, правило простое: хороший специалист в любой сфере крайне редко становится объектом отношений с агентством, он способен трудоустроиться самостоятельно. А сами агенты не унывают получая отказ от очередного целевого разработчика, они ничтоже сумняшеся просят предоставить контакты коллег или друзей, которые ищут работу или даже которых вы бы хотели трудоустроить в другую компанию (вот это, я понимаю, мотивация трудоустрой коллегу-конкурента и расчисти карьерный путь!).

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

Охотники за кошельками


Ну раз ИТ-специалисты много зарабатывают, почему бы не найти три тысячи способов честного отъёма этих денег. Соответственно, на базе всеобщего ИТ-фанатизма возникла целая индустрия, которая предлагает платные и слишком платные услуги. Перечислю некоторые из них.

  • Профессиональные конференции. Как вам стоимость билета в 20 или 40 тыс. руб.? И это не первая и не единственная проблема, которая связана с конференциями. Целые специализированные компании устраивают огромные конференции, настоящие фестивали, цель которых во многом собрать деньги за билеты и за места с компаний-участников, которые будут вас завлекать на стенды, а на самом деле хантить всеми возможными способами (квестами, задачками, конкурсами, розыгрышами призов и т.д.). При этом работодатели нередко выступают против участия в таких мероприятиях, т.к. боятся потерять специалистов, за которых они дорого заплатили и которые уже вжились в проект.

    Безусловно, очень круто послушать хороших спикеров, отборные доклады (тут программные комитеты не подводят), узнать о чужих проектах, но проблема в том, что это просто тусовка, редко когда удаётся какое-то услышанное решение утащить в продакшен или хотя бы принять как идею максимум, что выходит, это присмотреться к технологии и умозрительно примерить её на свой проект. Тем не менее именно конференции и фестивали активнее всего претендуют на часть вашей зарплаты, поскольку позиционируют себя отчасти как практически ценное мероприятие, отчасти как элитарный клуб. Хотя на самом деле всё гораздо прозаичнее.

Да и ковид внёс свои коррективы. Вопрос, надолго ли?

  • Школы английского языка. Хотите с носителем, хотите с преподавателем, хотите в мобильном приложении без общения. Очень много школ языка, которые ориентируются именно на айтишников, справедливо полагая, что в их профессиональной деятельности без английского никуда даже по Хабру это очень заметно. Между тем, мало кто говорит, что проку от таких школ именно в профессиональной сфере мало, здесь больше подойдёт погружение в среду, приоритетное использование иностранного на работе и в переписке, чтение книг и статей на английском. Школы больше помогут раскрепоститься и начать разговаривать, но профессиональная сфера зависит от вас и не так проста, как кажется.
  • Курсы программирования. Их просто сотни в любом городе, онлайн, при крупных компаниях и в вузах. Из них сильных и реально полезных единицы и, как правило, они оффлайновые и связаны с реальной практикой. Онлайн-курс может сориентировать вас, стоит идти в эту технологию или нет, понять, заходит или нет, но конечный результат будет зависеть от вашей практики, книг перед вашим носом и количества разобранных мануалов. Никакие потраченные деньги не помогут, если вы будете просто слушателем максимум вы научитесь отличать код на своём языке от всех остальных и выучите крутые разработческие словечки. Стоимость годового курса популярных онлайн-академий можно инвестировать в себя гораздо выигрышней.
  • Курсы повышения квалификации (в ИТ, менеджменте и т.д.) ещё один слой онлайн и офлайн образования. Scrum, Agile, управление проектами, курс продуктового менеджера всё для вас. Не буду рассуждать о том, что это даёт, скажу так: в книгах написано лучше. А для карьеры гораздо полезнее будет MBA (но и эта тема имеет кучу нюансов).
  • Эксклюзивные услуги трудоустройства. Сервисы поиска работы это вообще для лохов, как бы намекают нам эксклюзивные рекрутеры и обещают трудоустроить в Google, Apple и Microsoft с пол пинка. Но за это придётся заплатить либо вам либо работодателю (который потом при первом же случае вас этим попрекнёт), пройти платный курс, оплатить особое оформление и наполнение резюме. К слову, гарантии почти никто не даёт. Думаю, вы поняли, как устроен этот бизнес. Ваш опыт в любом резюме прекрасен, не стоит переплачивать там, где в этом нет необходимости.
  • Издательства профессиональной литературы. Есть офигенные зарубежные и отечественные издательства, которые выпускают классные книги (выделю Питер как лучшее из российских), а есть издательства, которые делают не очень хорошие переводы, публикуют не лучшие отечественные труды и при этом активно продвигают себя как лучших помощников на пути становления тимлидом, менеджером проекта, ведущим разработчиком. Здесь помогает только внутренний фильтр: пролистать книгу, почитать отзывы, оценить важность контента.

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

Охотники за идеями


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

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

Акулы всего


Сложившаяся индустрия спасла множество специалистов, которые в силу своего образования были обречены на сомнительное будущее. Да, я говорю о наших ненаглядных антагонистах гуманитариях. Помнится, в 2002-2007 гг. абитуриенты уже поняли, к чему идёт дело, и боялись поступать на филфак, в иняз, в педагогический, полагая, что это сулит им безвыходное будущее. Но прошло менее 10 лет и все эти акулы пера и языка нашли себя в HR, переводческой среде ИТ (техписы, маркетологи, продажники), в копирайтинге (управление контентом, редактура блогов и блогов на контент-площадках), в event-менеджменте (организаторы многочисленных мероприятий), особо наглые и уверенные в себе пролезли в управление проектами. И это всё та же самая ИТ-сфера.

А что здесь плохого, спросите вы? Ребята выполняют важные рабочие задачи. Всё верно, так и есть. Но среди них велико количество тех, кто даже не пытается разобраться в информационных технологиях и, например, заворачивает крутые статьи из-за нескольких косноязычных предложений, делает жуткие технические переводы, продаёт без понимания технических нюансов и требований клиентов на удачу, превращает грамотный Agile и Scrum в детскую, но строго обязательную игру с доской и бумажками, отнимает время на различные свои инициативы типа совместных офисных встреч, квизов и прочей фигни, которая устраивается после работы, но так же обязательна, как Scrum-доска. Эти ребята составляют сложные анкеты и инициируют психологическую и мотивационную аттестацию технарей, рассуждают о выгорании и токсичности, но при этом не особо готовы предлагать решения. Откуда в них заряд этой бурной деятельности? Всё просто: каждый из них проявляет активность, чтобы продемонстрировать свою деятельность, нужность и ценность для компании. Увы, нередко за счёт профессионалов, которые админят, пишут код, проектируют, тестируют и совершенно не хотят заполнять 127 вопросов анкеты о мягкости стульев, столовой и отношениях с коллегами. Потому что галочка на проекте аттестации будет, а стулья останутся неудобными, коллеги конфликтными, столовая так себе.

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

Глава 3. Войти в айти


Мнимая простота


Кажется, что работа в ИТ-сфере это просто. В самом деле, что такого-то? Во всех языках программирования очень ограниченное количество команд и вполне внятный синтаксис, задачи системного администратора тоже конечны, не говоря уж о тестировщиках подумаешь, пользоваться программой и искать баги. Именно так ты думаешь, когда идёшь на свой первый курс вуза или курс корпоративного университета для смены специальности. А спустя некоторое время ты же лежишь на клавиатуре и чуть не плачешь, потому что компилятор выдал 314 Errors, команда bash не существует, скрипт PowerShell делает не то или не делает ничего, а ты в довершение всего назначил всей аудитории 127.0.0.1 по DHCP. А дороги назад уже нет, и это только начало.


Да, относительно просто можно научиться клепать сайты на CMS, делать простые мобильные приложения, но задайте себе вопрос насколько это востребовано рынком и какова будет конкуренция среди таких умельцев на фрилансе?

Востребованные и классные специалисты проходят сложный и долгий путь: каждая тема, каждый язык программирования, любые объекты администрирования таят в себе тысячи нюансов, понимание которых приходит порой спустя много лет обучения и работы. При этом единственный способ продвинуться в своей специальности это ежедневная практика, работа с кодом, с железом, с сетями. Даже прочитав все книги, от Шилдта до Таненбаума, нельзя стать профессионалом, если просто читать и ничего не делать руками, не щупать компилятор, настройки операционной системы, не разбираться в алгоритмах, паттернах и т.д.

Увы, миф о простоте вхождения в ИТ будет расти и дальше, во многом благодаря многочисленным школам программирования, готовым за ваши же деньги и ваше время убедить вас в том, что вы уже труЪ кодер и заоблачная зарплата почти что зачислена на карту. Самое удивительное, что упомянутых HR-ов нередко восхищает наличие таких сертификатов, это работает по принципу ого, насколько мотивирован человек и как он заставил себя засесть за учёбу в свои 33. Я был свидетелем совершенно потрясающей истории, как парня с семилетним опытом работы в ИТ-проекте не взяли менеджером проектов в большую региональную ИТ-компанию, а отдали предпочтение девушке без единого дня опыта в ИТ, которая на собеседовании рассказала, что проходит курс JavaScript в одной из онлайн-школ. Курс она бросила, а работа с оплатой выше рынка осталась.

Кто хочет быть миллионером?


Да, есть разработчики, которые получают 200, 300 и даже 500 тысяч в месяц. Как правило, это ребята с каким-то уникальным сочетанием скиллов например, специалисты по компьютерному зрению, математики-разработчики нейросетей, крутые специалисты по относительно редким языкам программирования, гуру энтерпрайза и т.д. Но их не так много. Для позиций уровня middle часто по деньгам выгоднее быть менеджером проекта, менеджером по продажам и т.д., то есть занимать управленческие позиции.


Да, программисты получают заработную плату выше, чем средняя по рынку, но и трудозатрат и способностей такая профессия требует несравнимо больше. Фактически это непрерывный, напряжённый интеллектуальный труд. Иначе хорошо не получится, получится ниже среднего во всех смыслах. Условно говоря, если вам сейчас 35, вы получаете 60-80 тыс. руб., работая менеджером по чему-нибудь, линейным руководителем или инженером, и вы решите перейти в айти (разработку), то к своему уровню заработной платы вы придёте через 2 года минимум. А эти два года вы будете учиться и стажироваться, как обычный junior.

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

Стартап, это фальстарт


ИТ-стартапы это отдельная история, которая тоже формирует отрасль. К ним причисляют едва ли не любую вновь открытую компанию. Вот, какие они бывают.

  • Настоящие ИТ-стартапы компании, созданные небольшими командами, которые предлагают инновационные технологические продукты и разработки (например, приложения для слабовидящих, уникальные туристические гиды, медицинские устройства и т.д.). Они в меньшинстве, но интересные всем: и потребителям, и инвесторам и порой даже гос. структурам.
  • Новые ИТ-компании, которые не совсем стартапы обычные разработчики офисного ПО, игр, мобильных приложений. Ничего особо инновационного и интересного, но своё место на рынке находят. Таких больше, но всё равно не очень много.
  • Дети крупных корпораций и интеграторов, которые создаются для привлечения инвестиций, распределения рисков, снижения влияния сложившегося имиджа, продажи инвестору и т.д. У каждой такой компании свои цели и неплохое финансирование.
  • Конторы-дилеры различных вендоров офисного ПО, CRM-систем, CMS и т.д. партнёрские организации, которые берут готовый продукт, методику продвижения и пытаются выжить на рынке. Среди таких встречается совсем уж экзотика: студии растяжки и фитнеса продают CRM-системы, магазин товаров для детей пилит сайты на известной CMS и т.д. Это, конечно, не стартапы и не айти, но называют они себя именно так :-)

Так вот, эти стартапы весьма специфически относятся к найму персонала: например, в фазе активного привлечения инвестиций могут увести разработчика на большие деньги, а через полгода закрыться или просто избавиться от 90% персонала, потому что инвестиции иссякли, а продукт никак не взлетает. Более того, бывает, что программисты работают на самых низких условиях в предвкушении скорого завоевания рынка и в итоге вынуждены так ни с чем и уйти искать работу.

Глава 4. Что будет дальше?


Куда вырастет отрасль


Вопреки страшилками про роботов, ИТ-сфера не схлопнется и не исчезнет (кому-то же надо проектировать и программировать роботов!), а напротив, займёт ещё больше места в нашей жизни. Однако просто быть разработчиком будет всё скучнее и материально печальнее на рынке будет расти спрос на химер, то есть на специалистов, которые соединяют в себе умение делать хороший код и владение специализацией (например, в коммерции и рекламе нужны разработчики с пониманием маркетинга и программатика, в медицине биотех-специалисты, медицинские кибернетики и просто программисты с биологическим, химическим или медицинским образованием, в лингвистике нужны не филологи, а программисты с пониманием и знанием лингвистики и т.д.).

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

Отрасли нужны все


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


Какая **** сделала этот запрос?!

Образование должно меняться


То ИТ-образование, которое существует сейчас, должно будет измениться, иначе оно полностью потеряет свою популярность и актуальность (и даже армия не спасёт). В образовании должен быть упор на практические занятия, на обучение работе с источниками, на программы на стыке специальностей чтение лекций по методичкам из 90-х, квази факультеты информатики и краткосрочные курсы должны постепенно уйти в прошлое.

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

Технологии будут слабо меняться


Сегодня есть технологии практически для всего любая ваша идея легко обретёт свой технологический стек. Вряд ли что-то будет активно меняться в среде языков программирования, принципиально сдвинется в сетевой инфраструктуре, в вебе, в энтерпрайзе. Обученные сегодня программисты при относительно стабильном интересе к развитию своего стека будут востребованы и через 5 лет, и через 10 лет. К тому же, многие продукты ещё долго будут требовать поддержки и обслуживания (и да, сегодняшний современный, крутой и чистый код скорее всего через 10 лет будет геморройным легаси ;-) Подумать только!).

Технологии будут взрывно меняться


Всё, что касается мобильной разработки, нейросетей, искусственного интеллекта, VR/AR и IoT будет меняться с огромной скоростью. Многие современные реализации несовершенны и понятно, что разработка ищет новые пути, чтобы решить сложные задачи каждой из этих технологий. Развитие мобильной разработки будет определяться изменением форм-факторов гаджетов: гибкие экраны потребуют инноваций. Таким образом, в скором времени нас ждёт перелом в привычном стеке. Быть одним из первых в освоении новых методик по-настоящему перспективно, интересно и несомненно доходно.

IT станет попсой


Если 3-4 года назад ИТ-сфера была новым роком и формировала именно такую отраслевую субкультуру, то сегодня это уже почти попса. Такая эволюция произошла из-за того, что культуру для айтишников всё меньше формируют сами айтишники, всё больше подключаются мастера ивентов, шоу, культ-массовой работы и проч. Именно эти ребята будут создавать внешнюю оболочку нашей сложной и интеллектуальной отрасли и весьма возможно, что отрасль будет выглядеть так, как будто мозг Эйнштейна засунули в концертный костюм клоуна и пустили на работу. Это не хорошо и не плохо, единственное следствие такой ситуации внешняя привлекательность отрасли для широких масс, желающих войти в айти после двухмесячного онлайн-курса будет ещё больше, а значит, усугубятся зарплатные разрывы, упадёт качество управления и возникнут новые сложности при работе с заказчиками. Ну нам не привыкать.

Цикл возобновится


Рано или поздно накопится критическая масса описанных проблем и отрасль придёт к тому, чтобы нивелировать часть совершённых ошибок. Изменятся требования к профессионалам, вырастет ценность практического опыта, работодатели отвергнут всех, кто пришёл не формировать ценность, а забирать ресурсы. В итоге ИТ-отрасль качественно изменится и сформируется как широкое профессиональное сообщество, не готовое принимать слабых и неподготовленных вхожденцев (это будет нечто вроде модели медицины, куда войти не так просто). И это во всех смыслах интересная эволюция.

Перечитал текст мрачновато вышло В принципе, в будущее IT в частности и высоких технологий в целом я смотрю с огромным оптимизмом. При любых раскладах развития мировой политики и экономики (кроме уничтожения мира фантастика так фантастика даже по состоянию на июнь 2020) технологический шаг назад уже невозможен: всё больше элементов нашей повседневной жизни и трудовой деятельности будут базироваться на всё более продвинутых технологиях. Железо нужно будет проектировать, интерфейсы дизайнить, код писать в том или ином виде. Поэтому будет интересный рынок труда, будут разные зарплаты, будут запросы и будет спрос на всё, что сделано. IT-сфере жить и жить и я не буду говорить пафосных слов о том, что какой ей быть, определяем мы. Все мы люди и для нас работает вечная пирамида Маслоу, поэтому менять что-то за идею не получится только если очень локально. Но мы можем другое достойно и честно делать свою работу. Вот это реально определит состояние отрасли. А те, кто делают из отрасли поп-реалити-шоу, так и останутся мишурой. Они тоже просто делают свою работу.

Подискутируем?
Подробнее..

Scrum и Fixed Price в аутсорсинге совместить нельзя разделить

06.07.2020 12:10:38 | Автор: admin
Мало кто находит выход, некоторые не видят его, даже если найдут, а многие даже не ищут.
Из Алиса в стране чудес

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

  1. О противоречивости компонентов аутсорсинговой формулы Scrum + Fixed Price.
  2. Об одной, из возможных, ошибке (корневой причине), предшествующей неверному выбору инструмента Scrum.
  3. Об одной ситуации, когда действительно стоит вопрос о совмещении Scrum и Fixed Price, требующий глубокого анализа и поиска компромиссов для ее разрешения.


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




Как говорилось в статье С чего начинается псевдо-Scrum в аутсорсинге, в большом количестве аутсорсинговых проектов, команды которых совмещают (или, не исключено, выдают желаемое за действительное) Scrum и Fixed Price, не верно идентифицирован жизненный цикл (ЖЦ) проекта. Т.е. совершена ошибка в выборе между итеративным инкрементным или гибким ЖЦ. И, как результат, не верно выбран управленческий инструмент фреймворк Scrum. И уже следствием этого выбора является возникновение ряда проблем, неверных выводов об Agile, Scrum и попыток (от слова пытка?) совместить эти два взаимоисключающих понятия.

Взаимоисключающих?!

Сейчас аргументирую.

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

Scrum + Fixed Price это то же самое, что идти одновременно вперед и назад?


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


При заключении контракта на оказание аутсорсинговых услуг клиент практически всегда настаивает на Fixed Price (схема под ключ). Его пожелание зафиксировать Product Scope (или объем работ), увидеть бюджет, сроки. Он хочет видеть, что покупает. На Time & Material клиенты соглашаются редко.

Таким образом, ключевой момент: потребность клиента зафиксировать в контракте, а провайдера услуг выполнить обязательства по контракту и гарантировать, что параметры будут неизменными с прогнозируемой погрешностью (в силу некоторой степени неопределенности и рисков на этапах продаж и заключения контракта) после начала разработки. Вопрос понижения степени неопределённости и рисков это вопросы возможности проведения и качества фазы Discovery (Pre-sale, диагностики) в отношении Product Scope.

Совершенно очевидно, что, если мы что-то фиксируем (гарантируем клиенту по контракту), то мы обязаны спланировать и управлять этим таким образом, чтобы обеспечить выполнение своих обязательств. Т.е. управлять планом (или фиксированными характеристиками проектного треугольника).

Fixed Price просто обязывает нас поставить в приоритет управление планом. Иначе, зачем нам что-то фиксировать, заведомо зная, что оно изменится, и мы на самом деле не планируем этим управлять? Чтобы просто заключить контракт? Критическая ошибка устоявшихся процессов продаж: фиксируем, заведомо зная, что будем менять, лишь для того, чтобы подписать контракт!

Почему будем менять? Потому что Scrum это ведь всегда про неопределённость и ее результат изменения. Это про приоритет управления изменениями. И ведь не исключено, что они могут появиться уже после первого спринта. Почему?

Отступление о возможных причинах изменений

В чем может быть причина изменений? Она, например, может быть в некачественно проведенной фазе Discovery (Pre-sale, диагностики) в ситуации, когда Product Scope может быть определен в той или ной мере (для примера см. п. 3 из Case Study в статье), но по каким-то причинам этого не сделано. В таком случае, это проблема фазы и внутренних процессов, а не причина выбора Scrum для контракта с Fixed Price, гибкого ЖЦ вместо итеративного с целью компенсации допущенной ошибки.

Хотя, справедливости ради, отмечу, что в продажах (Pre-sale-активностях бизнес-аналитиков) в аутсорсинге (одна из самых проблемных фаз с точки зрения Product Scope!) не все так просто как в магазине, когда покупается готовый товар с конкретными свойствами (функциональностью). А фаза Discovery сложно продаваемая активность бизнес-аналитиков и команды. Но минимизация в той или иной степени неопределенности и оценка рисков одна из главных задач грамотно выстроенного процесса продаж. Как и формирование понимания у клиента о необходимости и важности этих активностей (бывает очень сложно!). Но для этого существует достаточное количество техник и инструментов. И это сводится к вопросу качества оказываемых услуг, а не продажи кота в мешке.

Другая причина может быть в невозможности определить Product Scope & Vision на текущий момент (для примера см. п. 2 из Case Study в статье). И это действительно очень непростая и невыгодная для обеих сторон ситуация, когда возникает серьезное противоречие и поднимается вопрос о совмещении Scrum и Fixed Price при оказании аутсорсинговых услуг. Она требует тщательного анализа, дополнительных действий по формированию всестороннего понимания клиента (зачастую технически и идеологически далекого от реалий процессов разработки) о возможных сложностях и рисках и поиску компромиссных решений.

Итак, почему же выбирается Scrum? Чтобы управлять изменениями, которые, например, возникают в результате неверно проведенной фазы Discovery (Pre-sale, диагностики) либо когда Product Scope не может быть определен на данной фазе? В первом случае, на мой взгляд, это ошибочно. Во втором сложно реализуемо при Fixed Price.

Третий возможный вариант выбора Scrum как инструмента Agile, гибкого ЖЦ вместо итеративного инкрементного в ситуации, когда Product Scope проработан и зафиксирован на фазе Discovery (Pre-sale, диагностики), а в контракте Fixed Price, тоже на мой взгляд не рационален: зачем выбирать инструмент для управления изменениями (уводить из фокуса явно более приоритетную вещь план), когда их вероятность минимизирована?

Возращение к главной мысли статьи.

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

Но контракт с Fixed Price задает приоритет в управлении планом!

Таким образом формула Scrum + Fixed Price трансформируется в управление изменениями + управление планом одновременно. Задача менеджера управлять в разных степенях и планом, и изменениями, но в приоритете может быть только что-то одно: либо план, либо изменения.

Либо управление планом, либо управление изменениями это, своего рода, аксиома, заложенная в основы менеджмента и бизнес-анализа. Она отражена в базовых (и не только) руководствах для менеджеров (PMBOK) и бизнес-аналитиков (BABOK). А классификация ЖЦ (и их идентификация в отношении конкретных проектов) опирается на нее: есть ЖЦ, предназначенные для управления планом (например, Waterfall, итеративные инкрементные (IID)) и гибкие, Agile для управления изменениями. Выбор ЖЦ (а в последствии и инструментов) строится из того, чему в управлении отдается приоритет.

Гибкий ЖЦ это разновидность итеративного инкрементного ЖЦ для проектов с определенными доминирующими признаками/особенностями (список контрольных вопросов приведен в вышеназванной статье), позволяющими идентифицировать его как отдельный ЖЦ и направить все силы на управление изменениями. К этим признакам могут быть отнесены: невозможность здесь и сейчас достичь некоторой степени определенности Product Scope (самое важное!), поиск бизнес-решения (или его быстрая поставка бизнесу для формирования обратной связи), которое выстрелит, формирование списка ключевых функций продукта (Key Features), короткие итерации, изменчивость, эксперимент, постепенное наращивание функционала, ретроспективы, совершенствование не только продукта, но и процессов с целью получить лучший вариант продукта. Возможно ли в таких условиях получить адекватные оценки бюджета и сроков?

Дьявол всего в одной детали или все дело в Product Scope


Во всем есть своя мораль, нужно только уметь ее найти!
Из Алиса в стране чудес

Что вы можете сказать об определенности (возможности ее установить) в отношении Product Scope & Vision на этапе продаж, фазы Discovery, на старте проекта в аутсорсинге?

Если Product Scope не может быть определен, оценен, зафиксирован по причинам уникальности продукта, идеи старт-апа, неизвестности в отношении эффективности принимаемых бизнес-решений (необходимости их поиска) и сложности определения ключевых функций продукта, наличия гипотез, требующих проверки и т.д. (см. еще раз п. 2 из Case Study тут), то, конечно же, фреймворк Scrum наиболее подходящий инструмент.

Однако, для аутсорсинга данная ситуация значительно осложняется пожеланием клиента использовать схему Fixed Price при заключении контракта и предстает в невыгодном свете для обоих сторон. В какой-то мере с некоторыми допущениями можно достичь компромисса при заключении контракта и при управлении таким проектом. Важно сформировать правильное понимание и верные ожидания клиента (инвестора), оценить риски, рассмотреть по возможности иные схемы финансового взаимодействия, а в процессе реализации проекта постоянно работать с лояльностью клиента и т.д. Углубляться в вопрос не буду, так как он выходит за рамки статьи.

В аутсорсинге чаще всего вопрос в первую очередь заключается в грамотном проведении фазы Discovery (Pre-sale, диагностики) в отношении Product Scope и выборе верного ЖЦ. И если выбирается Agile и Scrum в ситуации, когда Product Scope зафиксировать можно (и тем более, когда этого не было сделано по каким-то причинам вовремя, с ожиданием/предположением его проработки в будущем), и при этом в контракте Fixed Price, на мой взгляд, совершается ошибка, которая ставит под сомнение положительный исход проекта.

Спасибо за внимание!
Подробнее..

Перевод Чеклист для проекта по машинному обучению

07.07.2020 12:09:02 | Автор: admin
image

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

Зачем мне вообще нужен чеклист?

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

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

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

Как говорит Атул Гаванде в своей книге The Checklist Manifesto,
объем и сложность того, что мы знаем, превзошли нашу индивидуальную способность правильно, безопасно и надежно предоставлять свои преимущества.
Итак, позвольте мне провести вас по этому четкому и краткому списку действий, которые уменьшат вашу рабочую нагрузку и улучшат ваши результаты

Чеклист проектов по машинному обучению


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

1. Определите проблему с точки зрения высокого уровня


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

  • характер проблемы (контролируемая/неконтролируемая, классификационная/регрессионная),
  • тип решений, которые вы можете разработать
  • какие показатели вы должны использовать для измерения производительности?
  • является ли машинное обучение правильным подходом к решению этой проблемы?
  • ручной подход к решению проблемы.
  • неотъемлемые предпосылки проблемы

2. Определите источники данных и получите данные


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

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

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

3. Первоначальная разведка данных


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

Шаги:

  • используйте Notebook Jupyter, поскольку он обеспечивает простой и интуитивно понятный интерфейс для изучения данных.
  • определите целевую переменную
  • определите типы особенностей (категориальные, числовые, текстовые и т. д.)
  • проанализируйте соотношение между особенностями.
  • добавьте несколько визуализаций данных для легкой интерпретации влияния каждой функции на целевую переменную.
  • документируйте свои результаты исследований.

4. Исследовательский анализ данных для подготовки данных


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

  • Написание функций для преобразования данных и автоматизации процесса для предстоящих пакетов данных.
  • Напишите функции для очистки данных (вменяя пропущенные значения и обрабатывая резко отличающиеся значения)
  • Напишите функции для выбора и проектирования особенностей удалите избыточные особенности, отформатируйте преобразование объектов, и другие математические преобразования.
  • Масштабирование особенностей (features) стандартизация особенностей (features) .

5. Разработайте базовую модель, а затем изучите другие модели, чтобы отобрать лучшие


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

  • Обучите несколько часто используемых моделей, таких как модель наивного байеса, модель линейной регрессии, SVM и т. д., используя параметры по умолчанию.
  • Измерьте и сравните производительность каждой модели с базовой и со всеми остальными.
  • Используйте N-кратную перекрестную проверку для каждой модели и вычислите среднее и стандартное отклонение показателей эффективности по N-кратным показателям.
  • Изучите особенности, которые оказывают наибольшее влияние на цель.
  • Проанализируйте типы ошибок, которые допускают модели при прогнозировании.
  • Проектируйте функции по-разному.
  • Повторите вышеупомянутые шаги несколько раз (методом проб и ошибок), чтобы убедиться, что мы использовали правильные функции в правильном формате.
  • Составьте шорт-лист лучших моделей на основе их показателей эффективности.

6. Точно настройте свои модели из шорт-листа и проверьте наличие методов ансамбля


Это должен быть одним из решающих шагов, когда вы приближаетесь к своему окончательному решению. Основные пункты должны включать:

  • Настройка гиперпараметра с использованием перекрестной проверки.
  • Используйте методы автоматической настройки, такие как случайный поиск или поиск по сетке, чтобы найти лучшую конфигурацию для ваших лучших моделей.
  • Тестируйте ансамбль методов, такие как классификатора голосования и т. д.
  • Протестируйте модели с максимально возможным количеством данных.
  • После завершения работы используйте тестовый образец, который мы отложили в начале, чтобы проверить, хорошо он подходит или нет.

7. Документируйте код и сообщайте свое решение


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

  • Документируйте код, а также ваш подход ко всему проекту.
  • Создайте информационную панель, например, voila, или проницательную презентацию с визуализацией, которая не требует пояснений.
  • Напишите блог/отчет о том, как вы анализировали особенности, тестировали различные преобразования и т. д. Опишите свое обучение (неудачи и методы, которые сработали)
  • Закончите с основным результатом и будущим объемом (если таковые имеются)

8. Разверните свою модель в продакшен, мониторинг


Если ваш проект требует тестирования развертывания на реальных данных, вы должны создать веб-приложение или REST API для использования на всех платформах (web, Android, iOS). Основные пункты (будут варьироваться в зависимости от проекта) включают в себя:

  • Сохраните вашу окончательную обученную модель в файл h5 или pickle.
  • Обслуживайте свою модель с помощью веб-сервисов, Вы можете использовать Flask для разработки этих веб-сервисов.
  • Подключите источники входных данных и настройте конвейеры ETL.
  • Управляйте зависимостями с помощью pipenv, docker/Kubernetes (на основе требований масштабирования)
  • Вы можете использовать AWS, Azure или Google Cloud Platform для развертывания своего сервиса.
  • Делайте мониторинг производительности на реальных данных или просто для людей, чтобы они могли использовать вашу модель со своими данными.

Примечание. Чеклист может быть адаптирован в зависимости от сложности вашего проекта.

image

Узнайте подробности, как получить востребованную профессию с нуля или Level Up по навыкам и зарплате, пройдя платные онлайн-курсы SkillFactory:



Читать еще


Подробнее..

Категории

Последние комментарии

© 2006-2020, personeltest.ru