😩 Больше команд - больше проблем

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

LinkedIn: Cesario Ramos, Senior Management Consultant - AgiliX Consulting

📖 Читать статью (~6 минут)

📖 @pmbbk / #meme

📖 @pmbbk / #meme

🚀 Исповедь лида о том, куда расти дальше

Я лид команды - и хочу идти дальше вверх! Точнее, не уверен, что хочу, но в айтишке надо ведь расти и развиваться, значит, следующая позиция для меня - менеджмент на уровень выше. Или нет? Как пробиться на новый уровень, если компания нанимает на руководящие позиции извне? На чём фокусироваться? Как перестать скучать по разработке? А может, к ней надо вернуться? Знакомы такие рассуждения? Тогда эта статья для вас.

LinkedIn: Максим Шульга, Руководитель департамента разработки - МойОфис

📖 Читать статью (~8 минут)

📖 @pmbbk / #meme

📖 @pmbbk / #meme

🏋️‍♂️ Закон Галла

Перед нами способный, но пока еще молодой руководитель - Артемий. Он недавно устроился на новое место, где ему поручили возглавить команду. Осмотрелся Артемий, изучил, как всё устроено, - и ужаснулся. Бизнес-процессы кривые, логика отсутствует. Ему всё это не по душе. Решил: надо переделывать.

Для Артемия любые трудности - не барьер. Он не пасует: проблемы превращает в задачи, путаницу - в систему, а низкую продуктивность старается трансформировать в результат. Засучил рукава и сел писать подробный документ: в нём и новые роли, и схемы взаимодействия, и описание всех процедур, плюс целая коллекция инструментов под эти процессы. Куча нюансов, условий, исключений - работа титаническая. Бумага получилась на пол-отдела. Но теперь, считал Артемий, всё наладится. Он был горд.

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

И вот всё запущено - но не работает. Система лежит не подъёмным грузом. Слишком запутанно, перегружено условиями.

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

А где же он в начале ошибся? Нарушил один важный принцип: сложная, рабочая система может родиться только из простой, которая уже функционирует. Этот принцип вывел ещё лет 50 назад Джон Галл - по профессии, кстати, детский врач, но одна из его научных работ неожиданно стала основой теории систем.

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

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

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

Классика провала по Галлу - проект Google Wave. Планировался как супермессенджер: смесь почты, соцсетей и мессенджера. Получилось настолько навороченно и непонятно, что никто не стал пользоваться. Проект свернули.

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

Вывод: начинайте с простого. Пусть будет всего один отчёт и два правила. Главное - чтобы работало. А уже потом можно наслаивать и шлифовать.

Вот и Артемий это на собственном опыте понял. И теперь вы знаете - потому что он наступил на грабли за всех нас.

📖 @pmbbk / #idea

📖 @pmbbk / #meme

📖 @pmbbk / #meme

💰 Как рассчитать стоимость проекта, если вы о нём ничего не знаете

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

LinkedIn: Герман Лышков, Senior Project Manager - Далее

📖 Читать статью (~6 минут)

📖 @pmbbk / #meme

📖 @pmbbk / #meme

📖 @pmbbk / #meme

📖 @pmbbk / #meme

📖 @pmbbk / #meme

📖 @pmbbk / #meme

📖 @pmbbk / #meme

📖 @pmbbk / #meme

📖 @pmbbk / #meme