Comments 16

С "Я не хочу этого делать" как-то слишком просто. Банальное "не интересно" или "надоело" куда отнести? Вот лежат интересные задачи на разработку в бэклоге, а тут 100500 кейсов тестировать надо, или схемы рисовать или встречи организовывать. "Кроме тебя больше некому","мы в одной лодке" (ценность донесли и выбор объяснили) какое-то время может работать, но недолго, если для себя лично (не для проекта, не для команды, а для себя) интереса человек не видит. Освоил, может даже до автоматмизма основные вещи, а расти дальше не собирается.

Мне кажется, любое «неинтересно» можно раскрутить дальше.

Почему задачи в эклоге кажутся интересными, а рисование схем — нет? Возможных ответов много и каждый что-то большее, чем «мне просто неинтересно», значит к каждому можно найти решение:
  1. Рисование схем — глупая задача для джунов, а я хочу лютого хардкора.
  2. Схемы я рисую каждую неделю, хочется чего-то нового.
  3. Я просто не умею хорошо рисовать схемы и т.д.

С одной стороны, понятно, что всем нам хочется делать только то, что «интересно». С другой стороны, в любой работе всегда есть рутина и задачи, которые надо сделать через не хочу. Поэтому нужно учить себя находить новый интерес в рутине. У Людвига Быстроновского про это есть много рассуждений, на банальных примерах: чистить зубы 3 минуты каждый день неинтересно, но если начать их чистить другой рукой или под музыку или приседая одновременно, то на какое-то время это снова вернёт интерес.

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


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

Самое главное — начать диалог и понять внутреннюю мотивацию сотрудника.

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

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

По-моему, с этого нужно начинать. Хоть табличку завести "сотрудник — интересы/ценности" хоть по результатам опроса "кем себя видите через 5 лет" и задачи соответственно декомпозировать

> если человеку не интересно, то он не видит ценность именно для себя

спасибо за эту простую, но возможно очень полезную мысль, надо попробовать.
Спасибо за статью, тема близка и есть несколько вопросов.
1. Кросс-функциональность. Как мотивируете сотрудников? Что если человек не хочет развиваться туда, куда нужно команде, как мотивируете?
2. OKR для роста каждого сотрудника. Как измеряете, как мотивируете выполнять или даже вообще заниматься постановкой?
3. Кросс-функциональные команды это интересно, но как быть, если сотрудник хочет расти вверх, а не вширь? В LeSS и Scrum об этом как-то не упоминается.
4. Какая роль тимлида в кросс-функциональной команде, в которой все должны быть самостоятельны и разбираться в нескольких компетенциях? И команд как правило несколько, в каждой свой тимлид?
5. Почему у вас в кросс-функциональной команде только бэкендеры, QA и релиз-инженер (devops?)? Кто делает фронтэнд?
Спасибо за вопросы! Отвечу по порядку:

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

2. У нас есть грейды с описанием, плюс в каждой команде у Team Lead есть конкретные ожидания от каждого участника(так же прописанные в документе), плюс есть большой бэклог задач, некоторые из которых действительно сложные, плюс раз в пол года проходит Performance Review. В общем мы стараемся показать где человек сейчас, проговариваем куда бы они хотел расти, даем фидбек по тому, чего для этого не хватает и совместно придумываем план роста.

3. Вверх — менеджерская позиция? Или имелось ввиду вглубь?

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

5. Это специфика моей команды. Мы занимаемся высокими нагрузками, отказоустойчивостью и масштабированием в части бэкенда. Экспертиза во фронте бывает нужна редко, но даже для этого случая у нас есть человек, который в этом разбирается.
Так а кто у вас в компании/проекте занимается фронтендом? Это какая-то отдельная команда? А как тогда построено взаимодействие с ними? Как происходят совместные релизы?
У каждой команды есть область, за которую они отвечают и в которой пилят функционал.
Например, команда Canvas отвечает за базовое поведение канвы на клиенте и основные виджеты в ней. Для того, чтобы команда эффективно делала свою работу, им нужен бэкенд и фронтэнд инженеры.
Для команды Canvas-UX бэкенд инженеры практически не нужны, потому что цель команды — улучшать пользовательский опыт имеющегося функционала. В редких случаях, когда что-то нужно сделать на сервере, команда справляется своими силами.
Я правильно понял, что у команды Canvas есть необходимость как в бэкенд-разработчиках, так и во фронтенд-разработчиках, и поэтому данная команда не является кросс-функциональной? Или внутри все же есть разделение на две подкоманды?

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

Как раз команда Canvas является кросс-функциональной, так как в ней пересекаются несколько необходимых ей функций: бэкенд и фронтенд инженеры, QA, дизайнер, тим лид, product owner. В сумме команда состоит из 6 человек и внутри нет никаких подразделений.
Все участники команды направлены на решение одной конкретной цели. Например, если нам нужно реализовать новый виджет, то:


  • Product owner прорабатывает постановку и пользовательские сценарии
  • Дизайнер создает макеты и чистовой дизайн
  • QA подготавливает тестовые сценарии на основе пользовательских
  • Бэкенд инженер определяет схему данных и интерфейсы взаимодействия с клиентом, пишет логику на сервере
  • Фронтэнд инженер пишет логику на клиенте, ориентируясь на интерфейсы взаимодействия с сервером; внедряет дизайн.

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

Спасибо за ответ!
По 3 вопросу — да, я имел в виду рост вверх, в управленцы :) Обычно в scrum и less об этом как-то вскользь упоминается.
Почему у вас в кросс-функциональной команде только бэкендеры, QA и релиз-инженер (devops?)? Кто делает фронтэнд?

Частое заблуждение, по-моему, что кроссфункциональная команда — это end-to-end, fullstack команда. Если говорить о Scrum-like подходах, то кроссфункциональная команда — это команда, способная реализовать какую-то user story без зависимостей от других команд. Но User Story вполне может быть записана наподобие "Я, как фронтенд разработчик, для реализации UI такого-то хочу иметь API endpoint..."

Но user story бывают разные :) не всегда же команда будет делать только API? Кроме того, такой подход (сначала 1 команда делает API, потом другая команда делает фронтэнд) увеличивает time-to-market, за который все беспощадно борются.

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

Only those users with full accounts are able to leave comments. Log in, please.