Менеджмент

Как машинки помогли выявить лучших продавцов

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

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

Также мы купили магнитную доску и расположили на ней 12 машинок. У каждого менеджера был месячный план в 1 млн рублей. Каждый день на планёрке менеджеры двигали эти машинки. Так все видели, кто сколько продал в этом месяце.

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

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

«О чем на самом деле думает проджект-менеджер во время митинга: перевод с корпоративного на русский»

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

Про оценку сроков

Каждому проджекту знакомо. Митинг с заказчиком и командой, вдруг, не согласовав оценку с менеджером, разработчик говорит: «Ну, это задача дня на четыре... Если ничего не помешает».
Тут же слышится от заказчика: «Фиксируем, через 4 рабочих дня будет готово».
Вспышка, шторм, помешательство. У проджекта в голове: «Ага, “Если ничего не помешает”, так вам ничего и не помешает, конечно. Сейчас начнется: мало ресурсов на сервере, срочный баг от другого клиента, а тестирование? В этой оценке указана только время разработки! Минимум неделя нужна. А обещать буду за 7 рабочих дней».
Проджект тут же говорит вслух на корпоративном: «Предлагаю заложить на задачу 7 рабочих дней с учетом возможных рисков и интеграции в основной процесс. Нужно обстоятельно убедиться, что функционал готов к релизу».
Заказчик недоверчиво фиксирует 7 рабочих дней на задачу — фух, пронесло 😓

Про «немного поменять ТЗ»

Это из фонда золотых цитат заказчиков: «Мы тут подумали и хотим немного улучшить концепцию. Фактически, всё остается по-старому, просто логика немного меняется».
С этого начинается внутренний диалог проджекта: «„Улучшить концепцию“... Это значит пришить к штанам капюшон и выкинуть 3 недели работы. „Логика немного меняется“ — это сделаем из грузовика экскаватор, новый движок, новая база данных и отказ от всего, что уже сделано».
Проджект говорит вслух: «Понимаю ваше стремление к улучшению! Давайте проведем отдельную встречу вместе с аналитиком, где вы подробно расскажете о новой концепции. Мы проведем анализ, посчитаем новые сроки и бюджет и обсудим решение».
(редко кто меняет изначальную логику, увидев новые сроки и бюджет 😉)

Работа PM — это искусство баланса между желаемым, возможным и реализуемым. Главное — сохранять спокойствие и дальновидность.

Подписывайтесь здесь или в тг: @projectmindset_pm

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

Логично предположить, что HR не ожидают увидеть там репозитории рабочих коммерческих проектов, а всего лишь хотят посмотреть на pet-проекты или вклад в open source.

Но на месте работодателя стоит задаться вопросом: «Когда разработчик этим занимался?»

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

А если кандидат занимался pet-проектами после основной работы, то у меня для вас плохие новости.

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

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

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

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

Есть несколько советов о том, как не зацикливаться на работе.

Во-первых, необходимо делать небольшие перерывы в течение рабочего дня.

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

Во-вторых, в офисе очень важны социальные контакты и поддержка.

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

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

В-третьих, планируйте работу на следующий день с вечера.

Чёткий план действий позволит не распыляться и закончить начатые задачи.

Иначе незакрытые гештальты будут преследовать вас вне офиса.

В-четвёртых, простройте чёткие границы между работой и домом.

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

Источники

• A Meta-Analysis on Antecedents and Outcomes of Detachment from Work

• Facilitating Detachment from Work: A Systematic Review, Evidence-Based Recommendations, and Guide for Future Research

• Detach to Thrive: Psychological Detachment from Work and Employee Well‑Being

Кого нанимать в стартап?

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

На что обращать внимание:

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

Кросс-функциональность. Да, сотрудник стартапа - “многорукий многоног”, иначе не назовешь! Ваши сотрудники должны уметь закрывать множество компетенций, но самое главное - им должно это нравиться. Сотрудники, которые не любят (не могут) делать сверхзадачи или живут по принципу “это не мои обязанности” в стартапах не приживаются. Есть прекрасное сравнение: в зрелом устойчивом бизнесе сотрудники напоминают гирлянду - цепь из одинаковых лампочек, каждую из которых можно легко заменить. А вот в стартапе каждый - это яркая звезда, которую очень болезненно потерять.

Высокая мотивация. Сотрудник стартапа в идеале должен сам “гореть” идеей проекта. Это будет существенно влиять на результативность труда и атмосферу в команде.

Задавайте “правильные” вопросы на собеседовании и ориентируйтесь больше на soft-skills: в стартапе это самое ценное! 

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

Выгоревший сотрудник это реальная проблема, а не «загрустил, пройдет». Она имеет такие вполне конкретные последствия:

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

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

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

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

На ИТ-рынке, в целом, заметен тренд на заботу о состоянии сотрудников. Хотя чаще он довольно поверхностный. Стандартный набор — ДМС, оплата спорта, тим-билдинг, корпоратив, индивидуальная работа с сотрудниками, материальная мотивация. Является ли это достаточным? На мой взгляд — мало, но допустимо. Например, психологов я в малом и среднем бизнесе не встречал, только изредка в корпоративном слое. Работу над положительной нематериальной мотивацией встречал где-то в 20-30% организаций.

Нулевого выгорания не достигли нигде (это невозможно из-за особенностей человеческой природы), но значительно снизить удавалось. Помню случай с ТехноНиколь времен пандемии — им за счет работы с выгоранием сотрудников удалось повысить производительность на 50%! По их оценкам они при этом снизили уровень выгорания с 80% до 20%.

Со стороны сотрудника:

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

Со стороны бизнеса:

Работа с выгоранием — это похоже на регулярную страховку: объем бюджета, который менеджмент готов потратить на проблему, и уровень риска, на который согласен. Где брать на это деньги? В фонде оплаты труда. Если выгорание присутствует — потери производительности — 5-50%. Это размер ФОТ, который потрачен впустую. Можно взять из будущего ФОТ 5% и получить прирост производительности в 10%. А это уже рост EBITDA и чистой прибыли.

Берегите себя, и своих сотрудников, коллеги!

И расскажите как у вас с этим?

Delivery Manager: где его место среди Project, Product и Program Manager?

Недавно я публиковал статью о различиях Project Manager, Product Manager и Program Manager. В комментариях закономерно возник вопрос: "А где же Delivery Manager?"

Давайте разберёмся!

В базовой статье я сознательно ограничился тремя ролями - PM, PdM, PgM.
Это клубок который действительно может ввести в ступор даже бывалых, который часто встречается в IT и лучше всего показывает разницу между управлением проектами, продуктами и программами.

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

Чем отличается: Delivery Manager = фокус на выполнении обязательств команды и стабильности поставки.

• Project Manager отвечает за проект: сроки, бюджет, риски.

• Product Manager отвечает за ценность и развитие продукта.

• Program Manager отвечает за синхронизацию множества проектов и продуктов.

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

Задачи Delivery Manager-а

• Следить за здоровьем процессов в команде (Agile церемонии, velocity, SLA).

• Снимать операционные блокеры, чтобы команда могла работать.

• Координировать взаимодействие с другими командами (DevOps, QA, Support).

• Мониторить метрики поставки.

Когда Product Manager уходит в стратегию и общение с рынком, а Project Manager в бюджет и отчётность, команде часто нужен человек, который держит фокус на ежедневной предсказуемости поставки. В крупных организациях Delivery Manager становится опорой для нескольких команд разработки, снимая с PdM и PM часть операционных забот.

Метрики эффективности Delivery Manager:

• Velocity & Throughput - стабильность скорости команды.

• Lead Time & Cycle Time - скорость прохождения задач.

• Defect Rate - качество поставки.

• Team Satisfaction - насколько комфортно команде работать в текущем процессе.

Delivery Manager - это не конкурент Project/Product/Program Manager, а их дополнение.

• PM, PdM и PgM отвечают за "что и зачем" (стратегия, ценность, цели).

• Delivery Manager отвечает за "как именно" на уровне повседневной работы команды.

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

А у вас в компаниях, есть ли отдельные Delivery Manager-ы или их функции выполняют PM/PdM?

Безработица в российской ИТ отрасли продолжает расти

Индекс hh.ru достиг максимального значения за всю историю. Сейчас он равен 13,7. Это значит что количество открытых вакансий по отношению к размещенным резюме стало меньше чем когда-либо.

Сравнивая с показателями индекса в 2019 году, когда он равнялся 2,7 - можно сделать выводы что ИТ специалисты становятся менее востребованы.

https://habr.com/ru/articles/855608/ анализ индекса 2019-2024

Практики работы с OKR: реальные примеры из команды Авито

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

Смотреть VK
Смотреть YouTube

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

Подписывайтесь на канал AvitoTech в Telegram, там мы рассказываем больше о профессиональном опыте наших инженеров, проектах и работе в Авито, а также анонсируем митапы и статьи.

70% процессов и изменений в организациях либо не достигают целей, либо превращаются в бессмысленные ритуалы

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

По результатам оценок участников конференции, мой доклад попал в топ-5 — очень приятная неожиданность.

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

Ну что вы скажете? С 12 минут до 3 секунд(!) сократил время поиска инструкций полнотекстовый поиск в KMS Gran.

Один из наших клиентов - IT-компания - хранила документацию в Google Docs и Telegram, что вызывало путаницу. В 2024 году внедрили базу знаний KMS Gran, создав разделы "Проекты", "API-документация" и "Ошибки и уроки".

Результат спустя год:

• время поиска инструкций сократилось до 3 секунд

• скрипты автоматизировали уведомления о новых версиях API, уменьшив время согласования релизов на 30%.

• за 6 месяцев количество багов в коде снизилось на 25%, так как разработчики быстро находили решения по прошлым ошибкам.

Статистика показала, что раздел "Ошибки и уроки" просматривали 80% команды, что привело к добавлению видео-разборов типичных ошибок.

А какие процессы хотелось бы улучшить в вашей команде?

Сервис «Контур.Толк» провёл исследование с участием 1500 респондентов из разных регионов страны: им нужно было назвать фразы, которые чаще всего раздражают в деловой переписке и на созвонах.

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

Вот как выглядит топ-10 слов и выражений, которые россияне терпеть не могут в деловой коммуникации:

• Канцеляризмы: «принять к сведению», «прошу рассмотреть»;

• Англицизмы: «синкануться», «скипнуть», «факап», «замэтчиться»;

• Фразы с давлением: «надо было вчера», «срочно», «прямо сейчас»;

• Сюсюкание: «коллегушки», «отчётик», «человечек»;

• Пассивный саботаж: «мне за это не платят»;

• IT‑жаргон: «фича», «баг», «фреймворк», «флоу», «закоммититься»;

• Мемы в переписке: «А ничего тот факт, что…?»;

• Псевдовежливость: «заранее спасибо», «спасибо за понимание»;

• Безликие приветствия: «доброго времени суток»;

• Фальшивая лёгкость: «можем по‑быстрому».

Как построить отказоустойчивую инфраструктуру на базе Bare Metal: кейс компании SEOWORK

SEOWORK — платформа для мониторинга и аналитики поискового маркетинга. Компания развернула IT-инфраструктуру на выделенных серверах Selectel.

• Основа инфраструктуры — выделенные серверы в дата-центрах уровня Tier III. Они связаны локальной сетью со скоростью до 10 Гбит/с и изолированы от интернета.

• За производительность отвечают процессоры AMD EPYC™ 7452 (32 ядра), 512 ГБ RAM на сервер и быстрые SSD-диски корпоративного класса в RAID объемом до 20 ТБ.

• Вся инфраструктура Selectel по умолчанию соответствует требованиям 152-ФЗ и защищена от DDoS-атак на уровнях L3-L4. Независимый трехмесячный пентест выстроенной системы, выполненный по заказу SEOWORK, подтвердил ее защищенность.

Подробнее о том, как компания развернула на Bare Metal производительную и отказоустойчивую инфраструктуру с SLA 99,8%, которая ежедневно обрабатывает более 600 ГБ данных, читайте в Академии Selectel.

Что почитать проджект менеджерам (и не только проджект)

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

Автор который меня реально удивил и чьи книги я бы назвал супер полезными - Элияху Голдратт, а его книги «Цель: процесс непрерывного совершенствования» и «Критическая цепь»— это настоящие пособие для тех, кто занимается менеджментом и хочет понимать принципы, цели и проблемы бизнеса как сложного механизма (а еще, как со всем этим справляться), а еще понимать, как стоит и не стоит управлять сложными проектами с точки зрения ресурсов и времени.

В чем основное ВАУ автора? Дело в том, что что книги вроде как не совсем учебник, а написаны в формате романа. Не ожидая чего-то прям невообразимого, я сел за чтение… и все. Оторваться совершенно невозможно!

«Цели..» - это история директора загибающегося завода и его битвы за то, чтобы их не закрыли к чертям. Через его проблемы, поражения и победы происходит понятное и практически применимое раскрытие основных принципов организации высокоэффективного бизнеса

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

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

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

• как определить правильную цель своего бизнеса;

• из-за чего даже самое передовое предприятие может рухнуть;

• что за «узкие места», как с ними бороться и как не создать новые;

• почему работа отнимает все отведенное на нее время;

• как ускорять выполнение проектов при ограниченных ресурсах;

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

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

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

3 неочевидные ошибки при выводе стартапа на рынок

Поделюсь сегодня опытом по составлению Go-to-market-strategy. Ошибки, которые совершают фаундеры при выводе стартапов на рынок, в целом, однотипны: это попытки сделать все фичи сразу, игнорирование действий конкурентов, некачественный анализ рынка или аудитории, ошибки при расчете Unit-экономики. Об этом мы уже много раз говорили. Поэтому сегодня расскажу о нескольких “подводных камнях”, которые не очевидны сразу, особенно тем, кто запускает стартап впервые.

Распыление усилий на все сегменты ЦА на первоначальных этапах

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

Распределение равных усилий между каналами продвижения

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

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

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

Вывод продукта на рынок - самый волнительный и ответственный момент для любого стартапа. Будьте гибкими, но последовательными!

Новая статья на Habr: Опыт t2 по масштабированию BI на 4500+ пользователей

Опубликовали большой кейс о том, как компания t2 (бывший Tele2) решила одну из главных проблем российского рынка аналитики — нехватку западных BI-решений.

Главные цифры кейса:
4500+ пользователей FineBI
400+ разработчиков отчетности
Кластерная архитектура с 6 нодами
3 года успешной эксплуатации

Ключевые инсайты:
✅ Как организовать автоматизированное обучение пользователей
✅ Почему безлимитные лицензии стали ключевым мотиватором миграции
✅ Как построить внутреннее сообщество поддержки в Telegram
✅ Зачем нужна поэтапная миграция с участием бизнес-пользователей

Для кого будет полезно
Руководителям аналитики — практический опыт масштабирования BI
IT-директорам — архитектурные решения и организация процессов
Аналитикам — понимание современных self-service подходов
Всем, кто планирует миграцию — реальные уроки и рекомендации

Бонус от GlowByte
В статье также рассказываем об образовательном ретрите по FineBI, который стартует 25 августа:
🔸 13-дневный марафон с обновленной программой
🔸 3 эксклюзивных вебинара: FineReport Pro, AI в аналитике, 3D-визуализация
🔸 Реальные кейсы от t2, Уралсиб, Циан и других компаний
🔸 Система призов за лучшие домашние задания

Читать статью полностью → https://habr.com/ru/companies/glowbyte/articles/939470/

«Введение в управление проектами внедрения ERP-систем» А. Э. Бобровников (2-е издание) - обзор книги.

Ссылка на книгу на сайте фирмы 1С.

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

Автор вроде бы опытный методист, теорией не перегружает, говорит на языке бизнеса. В книге по верхам собрано всё: от оценки сроков и бюджета до управления конфликтами и рисками. Акцент сделан на практику внедрения ERP на платформе «1С:ERP».

ЦА книги - это заказчик системы. А поскольку ассоциация 1С с продуктами для регламентированного учета всё ещё актуальнее других, отдельная глава посвящена тому, чем ERP-система отличается от системы для бухучёта (и почему она такая дорогая🌚).

Дальше - про стартовый этап проекта:
про функциональные требования и их сбор, у кого и как собирать, в каком формате
про выбор подрядчика (тендер) и этапы RFI, RFP, RFQ (если кто не знал, что это)
про fit-gap-анализ (в среде 1С это зовут еще выявлением функциональных разрывов)
и об оценке IT-инфраструктуры, включая нагрузочное тестирование, и расчет окупаемости.

Сам процесс внедрения может идти по принятым подходам (PMBOK, ISO, ГОСТ 34, Agile), а может и по фирменным методикам 1С (ТБР и т.д.). Стандартная модель - каскадная: инициация → анализ → проектирование → разработка → тестирование → ввод в эксплуатацию. Акцент на важности реинжиниринга бизнес-процессов (чтобы не автоматизировать хаос).

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

Документация - тут всё очень кратко, в основном про использование бизнес-нотаций (IDEF0, BPMN, EPC) и прототипирование.

Говоря про сроки и бюджет, автор касается методов оценок (аналогия, экспертная, PERT, «сверху вниз» и «снизу вверх») и вспоминает классику - «мифический человеко-час», ошибки планирования, скрытые доработки. Отдельная глава - про управление рисками, про типовые риски (текучка кадров, ошибки ТЗ, сопротивление пользователей), управление|борьбу с ними.

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

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

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

Обзоры и дайджесты по проектному управлению - на нашем канале.

Что делать, если ваш проект все ненавидят?

В новом выпуске «Свободного слота» разбираемся, как пробивать непопулярные решения и объяснять их команде без потерь. Гость сегодняшнего эпизода — Сергей Щербинин, CEO Faust Consulting, основатель сообщества «Безвотэтоговсего». Вместе с ведущими Сашей Прокшиной и Сашей Афёновым обсуждаем:

• что такое принцип ПВО;

• как не продать душу дьяволу ради результата;

• как заставить себя и команду делать то, что не хочется, но очень надо.

Смотреть VK
Смотреть YouTube

Подписывайтесь на канал AvitoTech в Telegram, там мы рассказываем больше о профессиональном опыте наших инженеров, проектах и работе в Авито, а также анонсируем митапы и статьи.

Иконка WhatsApp* на сайте: почему цвет фона лучше не менять? 

Я сознательно убрал логотип WhatsApp* с сайта своей адвокатской практики. Это было единственное изменение в предложенном макете дизайна. 

Иконка WhatsApp* располагалась почти на всех страницах сайта: "Главная", "Контакты", "Адвокат" и так далее. Потенциальный клиент мог кликнуть по иконке и создать чат со мной. 

Но был нюанс - мой веб-дизайнер представил иконку WhatsApp*, заменив на ней фон. 

Изобразительный товарный знак WhatsApp* известен цветовым сочетанием белого, серого и зеленого. На моем же сайте использованы другие основные цвета: синий, желтый и белый. 

Веб-дизайнер отрисовал иконку WhatsApp* в цветах моего сайта. Получилось стильно, но рискованно. Почему? 

В самом размещении логотипа WhatsApp* на сайте нет нарушения интеллектуальных прав правообладателя товарного знака - ВотсАпп ЛЛК (Калифорния, США). Тому есть простое объяснение. 

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

Например, вы видите сайт с именем "WhatsApp*" в доменной зоне ".com" и понимаете: здесь предлагаются к продаже товары правообладателя этого товарного знака. 

В моем случае логотип WhatsApp* на сайте не предназначен для индивидуализации моих услуг под брендом "WhatsApp*". Логотип лишь информирует о том, что клик по нему переведет пользователя сайта в чат с адвокатом - владельцем сайта. 

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

Другое дело - возможность нарушения авторских прав: 

1. Картинка товарного знака WhatsApp* кем-то нарисована. 

Значит, есть автор произведения искусства. И у него есть право на единоличное использование картинки, в том числе в сети "Интернет". 

2. Автор картинки передал интеллектуальные права на нее компании - владельцу товарного знака WhatsApp*. И компания запретила менять цвет в логотипе. 

Об этом я узнал из Условий предоставления услуг WhatsApp*: пользователю разрешено использовать логотип с учетом Руководства по фирменному стилю WhatsApp*. 

В Руководстве отсутствует разрешение менять фирменные цвета. Более того, в разделе "Вопросы-ответы" дан прямой запрет на изменение цвета в логотипе. 

3. Я рискую получить иск о нарушении исключительного права на произведение искусства. 

Логотип WhatsApp* зарегистрирован в России, что позволяет его владельцу обратиться с иском в суд. Основание - переработка логотипа без разрешения владельца и размещение переработанного произведения в сети "Интернет". 

Поэтому вы не найдете на моем сайте иконку WhatsApp*: ее фирменный стиль выбивается из моего стиля, а изменение стиля WhatsApp* незаконно. 

Поговорите с вашим адвокатом. Он предложит вариант оформления  на сайте кнопки, которая ведет на чат в мессенджере WhatsApp*. 

Узнать мой вариант решения можно, перейдя на сайт моей адвокатской практики. Ссылка в профиле. 

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

* Деятельность компании Meta Platforms Inc. (Facebook и Instagram) на территории РФ запрещена.

Практически каждый день я читаю и узнаю что-то новое про разработку. Решил начать вести посты в формате "Я узнал о... (какой-то факт)"

В краткой форме буду рассказывать о чем-то, что узнал за последнее время

---

Я узнал о... #1: FinOps

Задумка FinOps заключается в том, что мы начинаем считать расходы на DevOps и инфраструктуру в компании. Чтобы потом всё это счастье оптимизировать и сэкономить (в идеале, спрогнозировать расходы и риски).

Само название меня немного насмешило, потому что взяли "Ops" и добавили к нему другой префикс, чтобы выглядело солиднее

Стартапы очень любят таким же образом добавлять слово "Tech" ко всему подряд. Началось с EdTech и понеслось... AgroTech, FoodTech, PetTech, SleepTech, SexTech, HrTech.

Возвращаясь к сути: FinOps - это когда на уровне компании мы перманентно мониторим инфраструктуру, её загрузку и расходы, а затем ищем способы оптимизации.

McKinsey говорит, что от ~20% расходов на инфраструктуру в бигтехах уходят впустую. Следовательно, раз это нижняя планка, в среднем можно брать ~30%.

Например:

• сервера, которые взяли с запасом, и >50% ресурсов не используются (но оплачиваются);

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

• прожорливые сервера у проектов, которые не особо-то рентабельны (и стоит подумать уже об оптимизации кода).

Контроль делается за счёт того, что:

1. Мы начинаем в целом считать инфраструктуру, чтобы понимать, что в компании есть;

2. Затем мы начинаем мониторить утилизацию инфраструктуры, чтобы находить простаивающие ресурсы;

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

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

Есть софт, чтобы считать инфраструктуру в гетерогенных облаках. Есть Kubecost, который умеет считать расходы в k8s. Есть разные опции в Terraform, чтобы считать стоимость инфраструктуры.

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

Когда это нужно?

Пока расходы меньше $30к/мес. - должно хватать гугл-таблицы и зоркого взгляда CTO/DevOps'а. И дружеского вопроса команде: - "А зачем нам это?".

Когда расходы >$30к/мес. и оперативной памяти ответственного лица не хватает - можно начинать думать об автоматизации сбора метрик. Иначе до этого момента автоматическое сведение метрик воедино рискует просто не окупиться

---

Мой Telegram канал про разработку.
Мой open source проект для бекапа PostgreSQL - GitHub.

Потихоньку или “громко”: стратегии вывода стартапа на рынок

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

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

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

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

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