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

🔥 Agile умирает - и его убийца уже здесь. Имя ему - искусственный интеллект!
Заметили ли вы что многие Agile визионеры активно перетекают в сторону AI-консалтинга?

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

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

Может, Agile - это как Nokia в мире проектного менеджмента? Собственно у Nokia был замечательный Agile

Теперь думаю: это трагедия или естественный отбор? Agile ещё жив или уже пора хоронить?

Личное vs. рабочее: почему мы так по-разному реагируем на цифры

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

Почему мы в личных проектах переживаем в десять раз сильнее

На работе метрики — это просто цифры.

Упала конверсия? Соберём ретро, построим гипотезы, потестируем.

Вырос трафик? Посмотрим, что сработало, и масштабируем. Мы как будто в броне: есть данные, есть логика, есть процессы.

А теперь представьте, что у вас свой канал или блог. Маленький. И вот однажды утром вы открываете статистику — и видите минус два подписчика. Вроде бы ничего страшного. Но внутри уже начинается паника:

— Почему ушли? — Кто? — Последний пост был неудачный? — Может, я всё зря пишу?

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

Почему так происходит

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

Это классическая ловушка субъективной оценки:

• смешиваются результат и личность;

• отсутствует внешняя система координат;

• нет чётких KPI, а значит, любое отклонение воспринимается как провал.

Что с этим делать

Вот что помогает мне — и, возможно, сработает для вас:

1. Превращайте эмоцию в структуру. Вместо «я пишу плохо» — «вот 3 поста с меньшей вовлечённостью, посмотрю, что в них общего». Данные всегда мощнее домыслов.

2. Разведите зоны «личное» и «проектное». Даже в личном блоге можно сформулировать цель, темы, гипотезы. Так вы остаетесь автором, а не только героем текста.

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

4. Не обесценивайте масштаб. Ваши 150 подписчиков — это не «мелочь». Это 150 реальных людей. И вы с ними — не воронку настраиваете, а доверие строите. Это сложнее. И важнее.

Вместо вывода

Личный проект — это вызов. Он без фильтров. Он про вас. Но именно в нём можно вырасти вглубь, не только вширь.

Если вы тоже дрожите над каждой цифрой в статистике — вы не один. Это нормально. Главное — не дать этим цифрам обесценить то, что вы делаете.

И да, я всё ещё веду тот самый маленький канал. Иногда с паникой. Но всё равно — с текстами. Потому что это и есть мой способ выстраивать структуру в хаосе.

8 книг для продактов от Product Lead Garage Eight (⌒▽⌒)☆

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

Сохраняй ее книжные рекомендации, в которых найдёшь конкретные кейсы и практические советы.

Lean UX
Jeff Gothelf, Josh Seiden
Дает базовые принципы интеграции UX в Agile-команды. Освещает быстрые циклы тестирования, ориентир на пользователя и коллаборативную работу внутри команды.

Agile Product Management with Scrum
Roman Pichler
Классическое руководство по роли продукт-оунера в Scrum. Показывает, как формировать и приоритизировать бэклог, работать с видением продукта и быстро собирать обратную связь.

The Lean Product Playbook
Dan Olsen
Предлагает системный подход к поиску product-market fit через быстрые эксперименты и обратную связь. Помогает создавать именно те фичи, которые решают реальные проблемы пользователей.

Build
Tony Fadell
Автор — создатель iPod и Nest —  делится опытом построения прорывных продуктов и запусков, сочетая истории успехов и факапов. Покрывает навыки лидерства, маркетинга, управления командой и разработкой.

Communicating the User Experience
Richard Caddick, Steve Cable
Фокусируется на том, как правильно оформлять результаты UX-исследований, визуализировать и «продавать» идеи пользователям, заказчикам и команде.

Inspired и Empowered
Marty Cagan
В «Inspired» — практические основы создания технологичных продуктов (от Culture и Discovery до выхода на рынок). «Empowered» учит формировать сильные автономные команды, способные принимать решения без жесткой вертикали.

Escaping the Build Trap
Melissa Perri
Предупреждает о «ловушке фич», когда команда гонится за выпуском как можно большего количества функций в ущерб созданию реальной ценности. Даёт принципы перехода на outcome-driven подход.

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

В малом и микро бизнесе встречаются два вида контроля. Они в каком-то смысле противоположны друг другу по цели и методам осуществления.

В первом случае предприниматель чувствует облегчение, что кто-то занимается отделом продаж и старается не вдаваться в подробности. Во втором контроль — это способ справиться с тревожностью. Спросил, и вроде отлегло.

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

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

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

Костя Дубровин. Канал, книга.

Топ-3 ценности для участников в хакатонах

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

У нас, у Phystech.Genesis, по факту 2 клиента сразу: участники и компании. Участники нам не платят деньгами, но платят вниманием. Внимание целевой аудитории по сути есть главная ценность для компании-заказчика.

Недавно мы провели опрос среди нашей аудитории в канале и выявили эти топ-3 ценности для участников на хакатоне:

1. интересные задачи,

2. призовой фонд,

3. мерч.

Не менее интересна и 4ая ценность, которую многие компании недооценивают — карьерные предложения, им участники отдали 31% голосов.

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

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

CEO Phystech.Genesis, Алексей Марахин

Amazon впервые за 20 лет обновила логотип — теперь улыбка стала теплее и дружелюбнее. Компания привела к единому стилю более 50 своих брендов, включая Amazon Smile и Alexa. Новый дизайн разрабатывали 18 месяцев вместе с агентством Koto.

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

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

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

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

А у меня нет дедлайна. Думаешь тебе повезло? Нет. Это повод задуматься. Скорее всего у источника задачи нет стратегии, целей, долгосрочных планов, ожидания не соответствуют действительности. Он не понимает, что хочет. Задача - это идея, без понимания практического применения. Скорее всего ты в "болоте". Если компания "живая", дедлайн тебя настигнет. А может быть тебя хотят "слить" и это ловушка? Я видел такое, так бывает.          

Как найти и мотивировать экспертов на хакатон

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

Один из топ-3 барьеров — найти экспертов.
Что же делать?

1. Сходите к бизнесу, продактам, дизайнерам, разработке.

• Продакты и бизнес дадут ОС по ценности решения.

• Дизайнеры по UI/UX и презентации.

• Разработчики посмотрят код.

Собирать разнопрофильную команду экспертов на поток из 10-15 команд. Подходят НЕ только разработчики!

2. Донесите ценность до экспертов.

Какие возможности даёт хакатон экспертам:

• Получить идеи для решения задачи своей команды

• Прокачать софт скиллы для роста в компании

• Выступить спикером и получить яркий повод для премирования

• Передать знания участникам, таким образом прокачать собственное понимание

3. В крайнем случае вы можете привлечь внешних экспертов через подрядчика.
У этой схемы есть минус — участники не познакомятся с вашими людьми: образуется меньше связей с вашим брендом.

10 причин, по которым вы теряете энергию и мотивацию (и как этого избежать)

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

1. Незавершённые дела и висящие «хвосты»

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

Что делать: использовать методики типа GTD, Inbox Zero или просто ежедневно подчищать список «хвостов».

2. Самообман и несоответствие внешнего и внутреннего

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

Пример: вы — интроверт, но вынуждены постоянно выступать или продавать. Это изматывает.

3. Изоляция и потеря социальных связей

Человек — социальное существо. Отсутствие контактов, поддержки, принадлежности к сообществу снижает уровень дофамина, серотонина и приводит к хроническому истощению.

Вывод: хотя бы одно по-настоящему «своё» сообщество — must have.

4. Страх и недоверие

Постоянное ожидание опасности активирует симпатическую нервную систему — режим «бей или беги». Это энергетически дорогостоящее состояние.

Как помочь себе: работа с психотерапевтом, телесные практики, распознавание триггеров.

5. Информационный и эмоциональный перегруз

Новости, постоянные уведомления, рабочие чаты 24/7 — всё это сжирает ресурсы мозга. Сюда же — гиперответственность, невозможность «выключиться».

Решение: цифровой детокс, разгрузочные дни, физические нагрузки.

6. Нарушение сна

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

Инструменты: режим, трекеры сна, гигиена спальни.

7. Пища, алкоголь и интоксикации

То, что мы едим и пьём, напрямую влияет на уровень энергии. Переедание, алкоголь, курение создают нагрузку на печень, почки, ЦНС.

Принцип: чистое топливо — чище система.

8. Много разговоров и внутренний диалог

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

Что помогает: практика молчания, mindfulness, медитация.

9. Хронические болезни и энергетические “паразиты”

Любой «тлеющий» процесс — болезнь, незалеченная травма, токсичное окружение — отнимает силы. Даже если вы «не обращаете внимания».

Рекомендация: диагностика, профилактика, защита личных границ.

10. Разбалансированная сексуальная энергия

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

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

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

Карьерная игра на понижение

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

Зачем так делают? Давайте разбираться:

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

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

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

Для сотрудника понижение в должности часто выглядит как более безопасная альтернатива увольнению:

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

• Нет стресса поиска новой работы, кэшфлоу хоть и уменьшается, но не прерывается.

• Стаж идёт, рекрутер на новом месте будет доволен.

В остальном сплошные недостатки:

• Про рост можно забыть, чаще всего новая позиция для специалиста — стагнационная.

• Тебя сломали: плевать в общем-то на уважение коллег, в корпорации уважение это вообще довольно специфическая категория, а вот уважение к себе, эго точно страдают.

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

А бывает ещё, когда "дело не в тебе" и это чистая правда

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

Это выглядит как груминг дерева оргструктуры. Например, Amazon, Google и Microsoft используют такой подход: плохие менеджеры на выход, хороших разжаловать в исполнители, уменьшить отношение менеджеров к исполнителям в разработке (через сокращения и перелив).

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

Недавно прочитал, что идеальная Agile-команда -- как повара в кафе: подберут ингредиенты, приготовят блюдо персонально для клиента. Самое вкусное для конкретного гостя.

Представляете такую команду в реальном ресторане?

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

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

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

2. Высказываете замечания:
-- Вроде как картошку то стоило поварить..
-- На анчоусы (откуда?!) у вас аллергия,
-- Посуду бы конечно добавить.
Команда соглашается, но посуду решили добавить только в 3 спринт -- ресурсов не хватало и между идеей убрать анчоусы (да зачем вообще?!) и добавить посуду выбираете здоровье в ущерб брезгливости.

3. ...

4. ...

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

Но за 5 попыток наверно уже и наелся.

И ведь все как ты хотел! Что недоволен то?!

P.S. Agile — отличный подход. Но никакая методология не заменит здравого смысла и процесса, внутренней культуры. И ни одна методология не может применяться без изменений в любой сфере.
Панацеи нет, придется додумывать!

7 правил как промоутить сотрудников

В IT у программистов есть грейды. Это примерно то же самое, что разряды у слесарей. Линейка обычно такая: Junior, Middle, Senior, Team Lead. У нас она немного другая, но суть та же. Промоушен (с англ. “повышение”) — это переход на более высокий грейд. Моя компания использует грейды больше 5 лет, поэтому я решил написать 7 основных правил процесса повышения грейда.

 1.  Инициатива 🙋‍♂️

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

 2. Основная работа 🔩

Отчет сотрудника должен основываться на основных рабочих рутинных задачах, а не на дополнительных факультативных увлекательных проектах. Например, выбрать 3–5 показательных завершенных задач-достижений в рамках должностных обязанностей и рассказать о них.

 3. Матрицы компетенций 🛤❌

Это не зло, но и далеко не основа грейдов, как считает большинство. Это набор подсказок о том, какими хардами (hard skills — техническими навыками) можно похвастаться при написании отчета.

 4. Ценность 🏁

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

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

 5.  Зоны ответственности 🤝

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

 6. Помощь 🛟

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

 7. Непредвзятость ⚖️

 Выработайте объективный механизм принятия решений “да/нет” по промоушену. Если “нет”, то “нет”. Пересдача. Закройте глаза и забудьте, что перед вами знакомый человек. Перед вами безымянный винтик — и вы тоже винтик. Если вы требуете профессионализма от сотрудников — проявляйте его сами.

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

МойОфис Экосистема: мы собрали офисные инструменты в единую рабочую среду

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

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

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

Мы разделили наши продукты на 4 семейства и изменили их названия. Теперь это настольные документы («Документы Настольные»), чат и видеозвонки («Сквадус»), веб-документы («Документы Онлайн») и почта для организаций («МойОфис Почта» и «Мейлион»). Для упрощения навигации мы также обновили и названия приложений. Теперь текстовый редактор называется «МойТекст», табличный редактор — «МоиТаблицы» и так далее. Это позволяет легко идентифицировать все компоненты экосистемы по единому стилю наименований.

Читайте подробнее об Экосистеме МойОфис здесь.

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

Большинство инженеров любят быть героями. Я — люблю. Представьте себе хайлоад-продукт: куча пользователей, запросов, деньги летят миллионами. Система сложная, размазанная по разным серверам, а, пожалуй, даже по разным дата-центрам. В общем, всё мчится и бибикает. Но вдруг где-то откручивается гайка, труба отпадает, из неё бьёт пар. Экраны мониторов в командной рубке заливаются красным, женский голос повторяет: «Тревога! Прод лежит». Картина маслом.

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

Потому что вы становитесь не-за-ме-нимы. Представьте себе ситуацию в Готэм-сити, когда Бэтмен уехал в отпуск посерфить на Шри Ланке.

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

Обязанности роли «техлид продукта»:

 1️⃣ Ответственность за работоспособность продакшена и стейджинга (боевой контур и финальный контур тестирования). Причем, именно работоспособность: создаёт и изменяет эти контуры другая роль.

 2️⃣ Управление процессом устранения аварий: координация как внутренних, так и внешних специалистов, информирование заинтересованных лиц о статусе устранения аварии.

 3️⃣ Ответственность за анализ аварий: ведение Post Mortem (отчётов об авариях), разбор аварий с командой, постановка организационных и технических задач для предотвращения аварий по итогам анализа.

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

 5️⃣ Ответственность за актуальность документации по разворачиванию сервисов локально у разработчиков. 

 6️⃣ Ответственность за создание и поддержку тестовых контуров.

 7️⃣ Ответственность за актуальность документации по контрактам взаимодействия модулей системы.

 🎱 Контроль технического долга на продукте.

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

Для Флага всё это уже давно не теория, а рутина где-то с лета 2023 года. Роль техлида «склеивает» множество узких специализаций, таких как DevOps, Backend, Frontend, Mobile, PM и SA. Сейчас я спокоен, потому что знаю: аварии устраняются быстро, выводы делаются, наши продукты и процессы становятся надёжнее с каждым факапом. Да, факапы всё равно происходят, никуда от них не денешься. Зато узнаю я об этом из отчётов, а не из ночных смс и звонков.

От картотеки Лумана к современным графам: учим языки программирования с методом Цеттелькастен

В середине XX века социолог Никлас Луман разработал метод организации информации Цеттелькастен (Zettelkasten). Он создавал множество заметок и, чтобы не терять знания, начал вести картотеку. Система нумерации и ссылок помогала ориентироваться в карточках. У каждой заметки был уникальный номер, отражающий тему и дополнения.

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

Веб-разработчик в YADRO Дмитрий сохраняет заметки в сервисе Obsidian. Дмитрий услышал о ПО от инженера и блогера Николая Тузова и понял, что система, похожая на картотеку, ему близка.

Программа оказалась понятной, легко адаптируемой под разные задачи. Когда Дмитрий перенес данные из Notion в Obsidian, образовалось несколько графов: по Go, хешированию и базам данных. В этой базе знаний все концепции в Go пересеклись в двух точках — интерфейсе и горутинах. Есть еще слайсы, но в основном все «лучи» сходятся именно в эти две точки. 

Как Дмитрию удалось упорядочить большие объемы знаний и кому он рекомендует Цеттелькастен, читайте в статье →

«Первая Форма» представила новую админпанель для быстрой low-code настройки

В новой версии low-code BPM-системы «Первая Форма» представлена обновленная административная панель для настройки процессов. Её главное преимущество — редактор, который даёт администраторам системы возможность создавать автоматизации без глубоких технических знаний и привлечения IT-специалистов. Решение помогает быстрее настраивать и оптимизировать процессы.

В редакторе автоматизаций появилось три новых инструмента для работы с запросами:

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

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

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

«Обновлённый редактор “Первой Формы” решает ключевые технические задачи при настройке BPM-системы. IntelliSense для создания автоматизаций, инструменты анализа производительности SQL-запросов и система версионирования формируют комплексное решение, которое сокращает технический барьер между бизнес-требованиями и их реализацией».

Евгения Бушуева, руководитель проекта по тестированию нового интерфейса администрирования «Первой Формы»

Другие функции новой версии можно изучить в материале на сайте.

Секрет успеха и продуктивности раскрыт. Оказалось, нужно просто не откладывать неприятные дела, а сделать сразу, но плохо.

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

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

Делать хуже — не значит быть ленивым. Это избавляет от тревожности и даёт больше времени на восстановление.

Запоминаем: вы не ленивый, вы просто пытаетесь быть успешным.

Эффект Пигмалиона (Розенталя)

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

На самом деле, их конечно же не стало больше, просто мы их стали замечать.

Такое наше поведение является проявлением эффекта Пигмалиона (Розенталя) и является одним из когнитивных искажений (ошибок мышления - обожаю эту тему, вот и сюда ввернул).

Эффект Пигмалиона - ожидания человека определяют его действия.

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

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

А что автомобиль?

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

Отсюда есть 2 интересных следствия:

1. Просто формулируя цели — вы уже настраиваете себя.

Сформулировав цель вы получите результат больше, чем если не сформулируете и будете просто «копать-бежать».

Это лучше чем ничего, но точно недостаточно чтобы сделать прорыв.

OKR служит хорошей формулой для формулирования целей.

2. От ожиданий руководителя зависит результат сотрудников.

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

А знаете чей слоган «для способных на большее»? Пишите в комментариях

Неудивительно, что эти ребята сейчас активно внедряют OKR. Это уже становится частью их культуры.

Вебинар: как соответствовать 152-ФЗ

Привет, Хабр! Ровно через 10 минут, в 16:00 мск, проведем вебинар для тех, кто взаимодействует с персональными данными. Поговорим про законодательство, которое регулирует эту работу, и расскажем, как определить свой уровень защищенности. Присоединяйтесь!

Смотреть трансляцию:

на YouTube

в VK

Программа вебинара

• Что значит соответствовать 152-ФЗ

• Кто определяет уровень защищенности компании и как его проверить самостоятельно

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

• Как Selectel помогает соблюдать требования 152-ФЗ

Кому будет полезно 

• Всем, кто обрабатывает персональные данные

• Всем, кому нужно подтверждение соответствия 152-ФЗ

• Всем, кто думает, что в облаках небезопасно

Участникам вебинара отправим чек-лист вопросов для облачного провайдера по требованиям 152-ФЗ. За лучший вопрос подарим приз — нашего маскота Тирекса.

Смотреть трансляцию