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

Ждем вас через час на митапе для тимлидов

В 18:50 начнем TeamLead MeetUp — ивент для руководителей и тех, кто хочет ими стать. Присоединяйтесь к трансляции и задавайте вопросы!

Программа

👉 Zero Bug Policy — эффективный метод работы с качеством

Максим Овчаров, директор по разработке ядра облачной платформы в Selectel, расскажет, как улучшил работу с качеством в командах облака, как выбирал и внедрял ZBP, с какими проблемами столкнулся. Доклад завершится практикой. 

👉 Найми меня, если сможешь

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

Подключайтесь к трансляции:

➡️ в VK 

➡️ на YouTube

Pull/Merge Request для согласования требований и документации

Аналитики и технические писатели, признайтесь: сколько раз вы теряли время, сравнивая версии документов в MS Word? Компьютер тормозит, красные и синие правки сливаются в кашу, а поиск согласования в бесконечной переписке или Confluence превращается в квест.

Есть решение — берем механизм Pull/Merge Request и применяем его к текстам! Что получаем:

• Все правки в одном месте. Редактируйте несколько документов сразу и смотрите изменения в едином окне. Забудьте про переключение между файлами и версиями!

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

• Простое согласование. Назначайте проверяющих и получайте их апрувы прямо в интерфейсе. Никаких "ок" в письмах или мессенджерах!

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

• Экономия времени. Gramax объединяет редактирование, ревью и согласование в одном месте — больше не нужно жонглировать Word, Confluence и почтой.

И все это в Gramax! Как всегда: бесплатно и с открытым исходным кодом.
Все как в коде, только проще.

26 мая 2025 года платформе для сообщества профессионалов в сфере IT исполнилось 19 лет.

В рамках этого события был создан уникальный музей Хабра! Три цифровые эпохи — начало, настоящее и будущее IT — хранят 19 уникальных артефактов. Исследуйте эпохи, соберите коллекцию артефактов, получите звание «Архивариуса Хабра 19 000» и участвуйте в розыгрыше крутого мерча от компаний!

«Со слезами умиления и ностальгией мы создавали для вас Музей Хабра — интерактивную игру, в которой хабравчане становятся исследователями истории IT!», — пояснила команда Хабра.

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

Чтобы попасть на ретроспективу «Музея Хабра», нужно зарегистрироваться в телеграм-боте: https://t.me/habr19_bot

🔥 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-запросов и система версионирования формируют комплексное решение, которое сокращает технический барьер между бизнес-требованиями и их реализацией».

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

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