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

Дополнительное образование для менеджера в IT

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

Сейчас на рынке есть три дополнительных типа образования для менеджера:

Различные программы MBA для топ-менеджеров и руководителей. Все это стоит от 1,1 миллиона рублей и выше, занимает примерно год и проводится ведущими вузами столицы, включая Сколково. https://www.skolkovo.ru/programmes/skolkovo-mba

Изучив программы, пришло понимание, что это для ребят, кто метит в CEO и CTO позиции, для тимлидов и юнит-лидов выглядит избыточно.

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

Однако, изучив программы, пришло понимание, что во многих местах все делается через образовательный портал в заочном формате с тестами для галочки. И не выглядит, что там ты реально сможешь получить что-то большее, чем прочитав книгу "Настольная книга проект-менеджера". Исключением является программа от БАУМКИ, где все выглядит серьезно, но и цена — 130 тысяч рублей. https://do.bmstu.ru/napravleniya-obucheniya/upravlenie-proektami/upravlenie-it-proektami-v-it/

Курсы менеджеров в IT от частных контор. Это Стратоплан, Отус, Скиллбокс, Нетология, Яндекс Практикум и другие курсы. Естественно, это все — неофициальные сертификаты, которые котируются исключительно субъективно. Где-то отзывы хорошие от людей, прошедших курсы, а где-то говорят, что курсы были бесполезными, с информацией не большей, чем в рядовой книге. https://stratoplan-school.com/team/

Что по итогу:

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

Эта встреча могла быть сообщением в чате: 6 проверочных вопросов

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

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

• Зачем нам нужна эта встреча? Зачем мы проводим эту встречу именно сейчас?

• Что должно измениться после этой встречи? Конкретизируем эти ожидания, уточняем последствия. Какой ожидаемый эффект для команды, проекта или бизнеса? Если ничего не измениться, возможно встреча не нужна;)

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

• Что случится, если встречу не проводить? Если ответ — «ничего страшного», значит, её можно заменить асинхронным обсуждением.

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

• Какие решения/информация нужны до встречи? (Если участники придут неподготовленными, встреча может затянуться и быть бесполезной. Этот вопрос помогает заранее собрать данные).

Внедряем 1С по-взрослому в химпроме: 10 заповедей успешного перехода на 1С:ERP

К2Тех рассказал историю из жизни опыта К2Тех о том, как «КуйбышевАзот» за 7 месяцев перевели с Oracle на 1С, автоматизировав 284 бизнес-процесса.

В статье:
✔️ Дорожная карта проекта
✔️ Тонкости формирования рабочей команды
✔️ Методология внедрения на основе Oracle AIM, адаптированная под 1С
✔️ 110 доработок и 45 точек интеграции
✔️ Отказ от параллельной работы в 2 системах
✔️ И, конечно, 10 заповедей успешного перехода на российскую ERP-систему в химпроме

Читайте по ссылке

Ещё один метод приоритизации задач, о котором почти никто не говорит

Привет, это Иван, главред блога Unisender и автор телеграм-канала «цифровой домосед». И в своей работе я не раз допускал следующую ошибку:

• Брал на вычитку статью необычного формата / на сложную тему / от автора, с которым ещё толком не сработались.

• На предварительную оценку тратил очень мало: пробегался по диагонали → вроде всё ок → откладывал на потом.

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

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

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

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

Рискованные задачи — это как раз те, где много неопределённости и неизвестности. Задачи, по которым невозможно точно предсказать сроки выполнения или рассчитать количество необходимых ресурсов.

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

Часто что-то непонятное или сложное мы, наоборот, стараемся отложить на потом. Но такая практика только усугубляет проблему. Лучше «есть лягушек по утрам», как говорится.

Кстати, рискованные задачи и подход к ним чем-то напомнили мне головоломку 9 точек и 4 линии. Вряд ли можно понять, как её решать, чисто теоретически, имея лишь вводные. Зато решение легко приходит в процессе — когда, собственно, берёшь и делаешь, держишь в руке карандаш и рисуешь.

Эту колонку я писал для авторской рассылки «Честно». В рассылке каждую неделю маркетологи говорят о том, что их волнует в маркетинге прямо сейчас. Подпишитесь, чтобы не пропускать самые интересные колонки — всё пришлют прямо вам на почту.

Почему нам нужна смелость и безрассудство

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

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

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

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

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

Чтобы преодолеть появление этого антипаттерна, необходимо:

1. Снизить значимость ошибки. То есть если все регламенты выполнены, задача прошла тестирование, но при выкатке случилась какая-то проблема, то окей — это допустимый риск, с которым мы готовы работать. Это не повод вызывать команду и отчитывать её за ошибку.

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

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

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

Но к чему геройство…

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

4 совета, как начать цифровую трансформацию бизнеса и не утонуть в ней

По статистике BCG, 70% проектов цифровой трансформации терпят неудачу. Чтобы попасть в успешные 30%, нужно продумать роадмап изменений до мелочей и учесть кучу факторов. Собрали четыре совета, как сделать этот путь проще и эффективней.

1. Ешьте слона по частям
   
   Не пытайтесь объять всё и сразу, лучше нарежьте задачу на много маленьких шагов — чем они меньше, тем лучше! Запускайте цепочку небольших проектов и сразу тестируйте их на пользователях.

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

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

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

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

Зумеры говорят, что дедлайн — это токсично

Привет! Меня зовут Саша, скоро мне будет 33 года, и уже 8 лет я предпринимаю в сфере медиа и контента. Моя команда была типичным продуктом миллениала — регулярные овертаймы, выгорания, «надо — значит надо». Мы гордились тем, что могли «вытащить» любой проект, даже если для этого приходилось не спать ночами.

А потом пришли они.

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

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

Для зумеров забота о себе важнее, чем все дедлайны мира.

«Они вообще работать не хотят! Что происходит?» — спросила я у операционного директора Саши (она тоже уже пережила возраст Христа 🙂). Саша пожимала плечами. Сначала мы злились. Потом недоумевали. Меняли сотрудников, но сталкивались с тем же:

• Они не признают авторитетов просто так и не делают, потому что «надо».

• Для них работа — не вся жизнь. Другие приоритеты.

• Отказываются работать с проектами, которые не в их стиле или не резонируют с их ценностями.

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

И мы начали учиться и менять компанию, а не команду.

Вот что мы сделали:

1. Для общения с клиентом — отдельный менеджер (чтобы сглаживать углы и следить за дедлайнами). Ребята спокойно делают свою работу, а клиенты общаются с человеком, который говорит с ними на одном языке.

2. Расширили базу фрилансеров, работающих в разных стилях. У нас всегда есть «запасной» вариант.

3. Ввели чёткий график работы и не работаем, не переписываемся в выходные.

4. Мы не требуем ни от кого немедленного исполнения задач (если такой режим работы не был согласован заранее). Каждый член команды строит свой график самостоятельно. Но спрашиваем о возможности (!) реагировать на сообщения, отправленные в рабочее время, в течение 1-2 часов.

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

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

7. Мы со своей стороны — чётко выполняем свои обязательства и надеемся на взаимность.

8. Общее правило — никаких правил, только пожелание: относиться к своим задачам ответственно и с любовью.

Если бы я увидела этот список несколько лет назад — я бы покрутила пальцем у виска.

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

Зумеры — не странные и не «плохие работники». Просто, кажется, они первые, кто открыто сказал: «Работа — это важно, но не главное». И это здравая идея.

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

Это кайф, рекомендую.

Саша Иващенко — фаундер диджитал-издательства SVOEMEDIA, медиа-предприниматель, автор Telegram-канала «Александра — молодец». Эту колонку она написала для авторской рассылки «Честно». В рассылке каждую неделю маркетологи говорят о том, что их волнует в маркетинге прямо сейчас. Подпишитесь, чтобы не пропускать самые интересные колонки от крутых ребят — всё пришлём прямо вам на почту.

🌱Объясняем основы риск-менеджмента на репке

В известной русской сказке один дед посадил репку. Она выросла огромной, дед решил вытащить её, но не смог — в одиночку такой проект просто так не затащить. Тогда он собрал команду: позвал бабку, внучку, Жучку, кошку и мышку. Только благодаря командной работе дед справился с задачей.

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

🔮 Риск роста: будь готов к неожиданностям
Когда дед инициировал проект (сажал репку), он вряд ли предполагал, что она вырастет такой огромной. В реальной практике проект вида «репка-переросток» встречается не так уж и редко. Мог ли дед что-то с этим сделать? Конечно мог! 

Что можно сделать:

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

• На этапе планирования ответить на вопрос «а что нам будет нужно, если…?» и строить планы с учетом возможных рисковых событий. 

• Основываясь на риск-плане, сформировать резерв ресурсов — времени, денег и прочего. Например: «Сколько времени понадобится дополнительно, если репка будет зреть долго?», «Кто в итоге участвует в сборе урожая?» и так далее.

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

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

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

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

Что можно сделать:

• Сформируйте ресурсный план и соберите команду заранее, продумав роли каждого.

• Убедитесь, что все участники понимают задачу и готовы приступить к работе.

🧩 Риск несогласованности: тянуть в разные стороны
В сказке все участники тянули за одну сторону репки, что обеспечило успех. А вот в IT-проектах часто возникает «перетягивание каната» — каждый тянет в свою сторону.

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

Что можно сделать:

• Заранее определить подход и технологии.

• Убедиться, что цели и задачи понятны всей команде.

• Настроить регулярный мониторинг и следить, чтобы все двигались в одном направлении. 

⚠️ Риск упущенных возможностей: вовремя привлечь помощь
Мышку позвали в последнюю очередь, хотя ее вклад оказался решающим. А ведь иногда именно «незаметные», но важные участники команды (например, аналитик или DevOps) могут посоветовать лучшее решение.

Что можно сделать:

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

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

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

P. S. Первый пост из этой серии — про инфобез и семеро козлят.

Про задачи, роли и позиции

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

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

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

И третий уровень - позиция. Конкретная должность под конкретного человека.

В идеальном мире одна роль = одна позиция (или несколько одинаковых позиций). По факту сплошь и рядом бывает, что одному человеку приходится брать на себя несколько ролей. И это само по себе не страшно, пока соблюдаются два правила:

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

• Нельзя разделять одну роль между двумя позициями. Если вы договорились, что у вас аналитик и ТЗ пишет, и согласованием занимается, то тот, кому эта роль досталась, и должен это делать. Опять же, если постоянно согласование достаётся другому человеку - нужно либо перебросить задачу на другую роль, либо роль согласующего выделить другому.

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

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

В Duolingo выпустили руководство по созданию топового стартапа (64 страницы) — внутри вся мудрость компании за 14 лет работы. В сети уже прозвали книгу новой «Библией» для менеджеров и стартаперов. В основе книги 5 главных принципов Duolingo:

1. Думай на перспективу:

— Duolingo строит долгосрочную стратегию, а не гонится за краткосрочной выгодой.

— В приоритете — пользовательский опыт и удержание пользователей, а не прибыль здесь и сейчас.

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

2. Поднимай планку:

— Всегда старайтесь делать лучше.

— Duolingo нанимает только исключительных людей, даже если это занимает больше времени.

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

3. Доставляй результат:

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

— Важен принцип «clock speed» — придумали и сразу сделали.

— Если идея не работает, её быстро отбрасывают.

4. Показывай, а не рассказывай:

— Все решения должны основываться на данных, а не на субъективных мнениях.

— Краткость в коммуникации важнее длинных презентаций.

— Пользовательский интерфейс должен быть понятным без объяснений.

5. Делай это весело:

— Обучение не должно быть скучным – Duolingo использует игровые механики.

— Внутри компании поддерживается культура юмора и неординарного мышления.

— Уникальный стиль бренда. В случае с Дуо, он дружелюбный, но слегка безумный.

Разработчик из польской инди-студии Immersion Games, который занимался проектом VR-игры про фитнес, похудел в процессе работы на игрой. Он сбросил 30 кг за семь месяцев, пока делал Fitness Fables.

Про нетерпимость к неопределённости

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

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

— Вот план на квартал. Три фичи.

— Не, ты скажи, какая когда будет.

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

— Не, ну даты-то какие?

— Точные даты я тебе могу назвать, но они ж из головы будут.

— Пусть так, но пусть будут.

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

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

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

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

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

Российская ИТ‑компания ITGlobal разместила на сайтах с вакансиями объявление о найме в штат экзорциста, которому собирается платить от 130 тыс. рублей в месяц Специалисту придётся изгонять демонов из неэффективных сотрудников. Нужно переехать в Санкт‑Петербург — работа исключительно офисная, удалёнка в условиях не упоминается

30 минут лучше чем 60 (если вы понимаете о чем я)

Вывод в начале, чтобы и тут оптимизировать время!

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

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

Подробнее

Для контекста небольшое наблюдение за собой: раньше я пользовался Google-календарем, в котором по умолчанию встречи создавались на час. Визуализировалось все по умолчанию блоками по часу. Сейчас моим инструментом работы с календарем стал Outlook. В нем по умолчанию день разделен на блоки по 30 минут.

Конечно, это настраивается и в Google-календаре, только раньше я об этом не думал.

Что изменилось?

По моим впечатлением продуктивность увеличилась.

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

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

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

Почему это важно?

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

Внимание и сосредоточение требует усилия. И эффективное сосредоточение, во время которого вы продуктивны у взрослого человека обычно 45 минут. Мало?

Скорее нет. Например, у детей в разном возрасте это считанные минуты. Кажется, только к 12 или даже позднее эти центры мозга формируются до конца. Отсюда время одного урока - 45 минут. Скажете, что пары в универе длятся 1,5 часа. Да, и это не супер хорошо, кмк. Можно тут почитать разные рассуждения на эту тему (осторожно, Яндекс Кью). Отсюда же берет начало метод Pomadoro (нет, это не те, которые можно кинуть в автора).

Что еще можно прочитать

1. Что такое концентрация внимания и как и для чего её развивать (2022 г).

2. Как «научиться учиться» — улучшаем внимательность (2019 г).

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

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

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

И тогда я стал задавать прямой вопрос - а какой стиль работы в целом ближе? На развитие или на получение результата здесь и сейчас?

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

Людей с майндсетом Run:

• драйвит быстрый результат;

• не беспокоит необходимость возвращаться к одному и тому же предмету несколько раз;

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

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

А майндсет Change:

• драйвит картина чего-то большого и красивого - но впереди;

• не любит возвращаться к уже сделанному, предпочтёт более сложную реализацию на перспективу;

• предпочтёт потратить побольше времени на подготовку.

Тут задачи уже другие: выстраивание процессов, инфраструктурные проекты, доделывание продукта после MVP.

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

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

30 000 ₽ на тестирование облачных сервисов Selectel

Акция для юрлиц и ИП, которые еще не пользовались нашими продуктами.

Хотите сократить расходы на инфраструктуру в три раза, как Гардиум, и привыкли все проверять заранее? Мы поддерживаем ответственный подход к работе.

В Selectel вы можете получить до 30 000 бонусов на тестирование облачных сервисов в течение месяца. Так вы изучите на практике подходящие для ваших целей решения.

Как воспользоваться грантом

• Зарегистрируйтесь в панели управления;

• Опишите в тикете, какие сервисы в облаке хотите протестировать;

• Проконсультируйтесь с нашим менеджером;

• Получите промокод на необходимую сумму бонусов и активируйте его в течение 7 дней;

• Через месяц оцените результаты тестирования и примите решение о дальнейшей работе с облаком.

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

Об эталонном аджайле и мультикультурности

Работали мы как-то на проекте с немцами: огромный концерн, куча юрлиц. Помогали им визуализировать данные из БД на несколько миллиардов записей. И оказалось, что немцы и вправду очень педантичны в работе. Они строго следовали всем правилам и инструкциям. 

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

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

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

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

• Вывод 1. Не стоит слепо следовать даже самым популярным практикам. Подходите ко всему с умом, а не формально. Создавайте свой уникальный фреймворк, который подходит именно вашей ситуации и вашей команде.

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

• Вывод 3. Созвоны — зло, если их у команды разработки больше двух в день. Они убивают продуктивность у всех.

Больше об управлении проектами рассказываем в отдельном телеграм-канале.

У каждого своё одеяло

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

Теперь представьте, что одеяло — это задача, а спящие — специалисты. Если каждый занимается только своим "одеялом", всё будет идеально: комфортно, эффективно и без конфликтов.

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

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

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

Команда из девяти сотрудников Nokia в 2007 году выступила с внутренней презентацией, на которой объявила, что представленный первый iPhone от Apple может изменить стандарты индустрии и станет лидером рынка.

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

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

Культура и практика написания MoM (minutes of meeting)

Короткий пост о том, что это такое, зачем (и для чего) и, конечно, как.

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

Что такое MoM (Minutes of meeting)? 🤨

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

Зачем MoM?

• Юридическая значимость, если использовать email для фиксации позиций и решений (возможно, в мессенджерах тоже, но в email я уверен)

• Синхронизация представления о результатах встречи

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

Как MoM?

• Идеально - сразу после встречи (чтобы не забылось)

• Путь написания письма (email). Вспоминаем пункт про юридическую значимость

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

  • Кто был на встрече (участники)

  • Что обсуждали (ключевая тема, ответвления) 1±2

  • Что решили (ведь зачем-то собирались?)1±2

  • Задачи, которые появились на встрече. Кто исполнитель и, конечно, дедлайны по ним. Тут ограничений нет.

  • Следующая встреча - требуется ли, дата и время

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

Что еще можно почитать на эту тему:

• Учимся проводить совещания (2008 г)

• MoM: Как? Зачем? Почему? (2024 г)