#организационныйДизайн

Интересная статья о модели управления в Apple.

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

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

Авторы выделяют три основных принципа “яблочного” менеджмента:
1. Глубокая экспертиза: только эксперты имеющие прикладной опыт могут стать менеджерами какого-либо направления. В этом есть два базовых принципа: лучшие хотят работать с лучшими и из хорошего инженера проще сделать хорошего менеджера, чем наоборот.
2. Погружение в детали: руководители подразделений должны отлично разбираться не только в технологиях, но и деталях проекта, всех спорных вопросах и необходимых компромиссах. Минимум на три “этажа” под ними.
3. Готовность к совместному обсуждению: способность аргументированно отстаивать свои позицию в обсуждениях с другими командами.

Есть над чем подумать.

Привет! В глубинах YouTube наткнулся на фантастический курс о сложном мире от Георгия Сатарова.

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

Три наиболее интересных тезиса:
1. Хаос и порядок порождают друг друга. Граница между ними практически не различима: простые детерминированные алгоритмы порождают хаос; хаос разбивается на простые «осязаемые» компоненты.
2. [эволюция] Селекция и закрепление не скоординированы. Ни одна система не может управлять своей эволюцией: в силу неопределённости будущего никто не знает, какие характеристики позволят системе сохранить себя. Желательно иметь «излишек» характеристик, которые позволят быстро адаптироваться к изменившейся среде.
3. Система способная к обновлению получает шанс (!) на продолжение жизни.

И для ценителей: произведение Баха о хаосе и порядке.

P.S. Поскольку курс рассчитан на максимально широкую аудиторию, динамика достаточно медленная. Рекомендую слушать лекции на x1.5-x2

Open Space - это, на мой взгляд, самый эффективный и честный способ организации совместного взаимодействия. Каждый рассказывает то, что ему интересно и каждый слушает только то, что ему интересно.

Мой товарищ Никита Хромушкин (автор канала @product_developer), организует онлайн митап, на котором можно будет увидеть, как работает эта техника на практике. Присоединяйтесь!

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

​Open Space Technology - инструмент для проведения мероприятий с большим числом участников.

В группе размером больше чем 6 участников обычно общаются два-три наиболее активных. При этом другие не имеют возможности высказать свое мнение.

Если не все выскажутся, это может привести к трём проблемам:
1️⃣ — Упустят какие-то важные аспекты;
2️⃣ — Примут менее качественное решение;
3️⃣ — Тот, кто не смог высказаться, может почувствовать себя ненужным.

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

Основная концепция Open Space - выделять аспекты общей темы и отделять обсуждение аспекта в отдельную комнату, куда придут все желающие поговорить именно об этом.

Предлагаю попробовать на практике на нашем митапе 1 апреля после работы.
Регистрация на Timepad

В посты на канале я стараюсь закладывать пространство для мыслей и обсуждений. Например, серия постов про зоны ответственности разработчика.
1 апреля в 19:00 соберемся в зуме, чтобы потрындеть как раз про зоны ответственности разработчика.
Вместо докладов будет свободное общение в формате Open Space.

Единственное отличие от классического Open Space - мы не будем принимать решения.
Каждое мнение правильное, нет цели принять какое-то одно за единственно верное.

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

Регистрация на Timepad

Увидимся! 🙂

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

А что думаете вы? Поделитесь в комментариях вашими мыслями/идеями/предложениями.

Friendly Asked Questions #1 — про уникального эксперта

Я руководитель команды из 10 человек. Когда мой разработчик Алексей уходит в отпуск, куча вопросов "встаёт" до его возвращения, нет никого, кто был бы настолько же в курсе отдельных частей проекта. Разработчику это похоже очень нравится, на моё предложение, чтобы он кого-то научил, передал свои знания реагирует агрессивно. Что делать? Если будут проблемы — всех собак повесят на меня.

Ответы дали авторы каналов Уютный Адочек, Человек и машина и Scrum Master Notes
А мы ждём ваших вопросов в: https://forms.gle/sKyaEuqQMMyFJBxJ8

@scrummasters — Василий Зорин

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

@manandthemachine@manandthemachine — Карен Товмасян

Ох уж эти Всезнающие Алексеи!
Позволю предположить, что Алексей в конторе был задолго до %username%, иначе непонятно, как подчиненный смог выстроить такую политическую игру.
Не стоит просить кого-то заняться обучением других, это должно быть не просьбой, а задачей.
Если же человек не хочет выполнить такое поручение, то стоит задаться вопросом, не боится ли этот человек потерять ценность для команды и проекта/продукта? Я уверен, нормальная встреча 1-1 приоткроет завесу тайны.
Но предположим, что Леха-карьерист таким образом решил кого-то (вас) подсидеть, и поэтому контакт не налаживается. Решение в таком случае жесткое: уволить и принять удар.
Да, с собаками придется повозиться, но я не слышал ни об одном предприятии, которое закрылось из-за ухода ключевого сотрудника.

@lovely_it_hell — Цупко Игорь

Многое зависит от того, сколько у вас времени на решение этой проблемы и какие есть доп. ресурсы. Когда они есть – можно либо вникнуть самому, либо попробовать организовать каким-то образом вытаскивание информации из Алексея (даже при наличии сопротивления).
Сложнее — если ресурсов нет.
Мне бы в первую очередь хотелось поговорить с Алексеем, чтобы, а) показать ему, что его job security в порядке и будет таковым; б) его ценят и любят за его экспертность и это так и останется даже если он будет делиться знаниями; в) понять его мотивы и попробовать придумать, как в них (и возможно ли) в них встроить идею о передаче знаний.
Если удастся договориться с Алексеем, то вытаскивание и распространение знаний станет уже его осознанной и прямой задачей и останется только помогать ему методологически и ресурсно. А если не удастся — надо попробовать найти способ аккуратно разойтись.