Архив рубрики ‘управление продуктом’

Почему раздувание штата не ускорит релиз — миф о линейном ускорении

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

Per aspera ad astra. Как построить космолет, не привлекая внимания санитаров

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

ROPI — индекс возврата инвестиций от продукта

Несколько лет назад я познакомился с работой Ицхака Адизеса где он рассуждал об эффективности работы руководителя. В это момент мне стало интересно, как оценивать эффективность работы меня как CPO, как оценивать работы всех команд, как понять что все команды приносят пользу? Вопрос кажется очень простым, но на поверку он намного сложнее. Команды работают не в […]

Размышления о документации

Вряд ли найдётся кто-либо, кто в здравом уме и ясной памяти будет отрицать необходимость документации. Любой продукт имеет (или должен иметь) свою документацию. Как минимум – инструкцию о том, как этим продуктом пользоваться. Производители почти всегда указывают – «прежде чем начать пользоваться нашим продуктом, внимательно ознакомьтесь с инструкцией».  

С толикой «крипоты» — откуда пришло понятие feature creep и как «ползучее расширение функциональности» вредит проектам

Мы в Beeline Cloud недавно писали о ретрософте, который живет и поддерживается вот уже не первое десятилетие. Сила этих программ кроется в отказе от лишнего. Во многом они выжили благодаря своей простоте: сохранили ядро, ключевую функциональность и лояльных пользователей. Поговорим о тех, кто все же не смог устоять. Разберем на примерах, как неконтролируемый feature creep […]

Консультант у руля: хроники пикирующего продукта. Как TGM из консалтинга похоронит вашу продуктовую команду

Всем привет! Хочу поговорить о той звенящей тишине, которая повисает в воздухе, когда на общем собрании объявляют имя вашего нового TGM. Молодой, энергичный, уверенный и с блеском в глазах: — «Предыдущий опыт? Консалтинг: запустил 100500 проектов в космос! Ну… почти 100500… почти запустил…» Топ-менеджмент хлопает в ладоши: «Наконец-то! Стратег! Визионер! Сейчас он всё разрулит! По-быренькому […]

«Один ушел — и все сломалось». Почему в ИТ-эксплуатации важно отслеживать Bus Factor и как это делаем мы

Привет всем! Меня зовут Гриша Капцов, я работаю в Отделе координации и поддержки продуктовых команд в МТС Web Services. В прошлом посте рассказывал, как мы с командой прокачали свой навык повелевания хаосом. А сегодня хочу обсудить ситуации, когда один «незаменимый» сотрудник становится угрозой. 

Как мы решились автоматизировать поиск работы в рунете и какие препятствия были у нас на пути…

Привет, Хабр! Это моя вторая статья, посвященная нашему проекту.  Мы создаем продукт, который, как мы верим, изменит рынок труда в Рунете — AI-ассистента для поиска работы, забирающего на себя всю рутину. А рутины, как выяснилось, очень много. В этой статье я постараюсь открыть больше внутрянки про техническую часть проекта и продолжу рассказывать про наши факапы […]

Культура ИТ экспериментов. Очередные первые 100 дней в новой компании

Каждая компания двигается по шкале от незрелой к зрелой и обратно. Это всегда динамика. Сегодня вы образец, завтра вы устаревшая помойка. Если 10 лет назад для наведения порядка внедрялся какой-нибудь «каскадо-водопадный PMI», 5 лет назад гибко-адаптивный Agile-OKR, то сейчас есть динамика к культуре проведения экспериментов*. Случилось это по разным причинам, одной из них считаю изменение […]

Ошибки на 15 млн ₽ и доход $3000: как 2 разработчика сделали своё приложение

Оглавление Интро Опыт в найме Стартовые условия для стартапа Финансовая ситуация и самообеспечение Запуск приложения и команда Трудности в процессе Что помогло и что помешало Что посоветовал бы себе в начале Итог истории Интро