Усі матеріали

Наступна модель, яку я використовую для розуміння компаній – це модель життєвого циклу Іцхака Адізеса. Більше про автора моделі можна дізнатися, наприклад, тут або тут. Взагалі, в мережі багато інформації і про Іцхака Адізеса, і про його здобутки.

Якщо модель спіральної динаміки, яку описано у частині 1, дає можливість з’ясувати, яка вона, компанія, де ти працюєш (починаєш працювати), то модель зрілості Адізеса дає можливість відповісти на питання «на якому етапі життя вона перебуває». Так, у компаній теж є свої етапи життя, і, як і людям, компаніям притаманні ті чи інші риси у поведінці, залежно від їх «ментального віку».

Взагалі, моделей зрілості дуже багато, і вони застосовуються до дуже широкого кола процесів та систем: від моделі зрілості бізнес-процесів (BPMM  About the Business Process Maturity Model Specification Version 1.0 | omg.org), до зрілості економік цілих країн (Industrialization as the driver of sustained prosperity | UNIDO). Далі, окрім моделі Адізеса, я запропоную розглянути ще кілька моделей в інших сферах, які, на мій погляд, будуть корисними для розуміння того, що оточує ІТ.

«Будь-яка пригода має з чогось розпочатися… банально, але навіть тут це правда…»

Л.Керрол. Аліса в країні див.

Отже, давай уявимо.

Нова робота в новій компанії. Ти прийняв(ла) офер. Працюєш уже кілька днів або тижнів і намагаєшся зрозуміти, куди ти потрапив(ла). Чого чекати від співробітників та керівництва? Як будувати відносини з людьми навколо?

Як це зробити?

Мені, як кібернетику, не спало на думку нічого іншого, ніж використати запропоновану ще у 1937 році Карлом Людвігом фон Берталанфі в його загальній теорії систем ідею: віднести саме цю окрему компанію до якогось загального класу систем, а потім знайти опис таких систем (більше про фон Берталанфі можна почитати, наприклад тут, а про теорію систем тут).

Тобто я хочу використати поради розумних та досвідчених. Швидше за все, люди вже напрацювали певні висновки щодо того, як поводитися в тих чи інших ситуаціях, перебуваючи в тих чи інших компаніях. Класифікували ці напрацювання. Треба тільки пошукати ці класифікації і зрозуміти, до якого класу належить «твоя» компанія.

Нижче я наведу кілька класифікацій (моделей), які, на мій погляд, є корисними для розуміння оточення. Зауважу, що це лише мій погляд і мій досвід використання. Кожен може використовувати власні підходи: від гороскопів і нумерології до ще більш "просунутих" підходів.

Отже, перше, про що хочеться поговорити — це про кольорові організації.

Якщо постояти будь-де досить довго, за тобою вишикується черга.

«Закони Мерфі та пов'язані з ними висновки»

Сьогодні хотів би поговорити про розробку й підтримку. Поділитися, як мені здається, вдалим прикладом боротьби з потоком важливих і термінових завдань, потрібних на вчора… Точніше, створення правил роботи з рутинними завданнями розробки.

Правил, які дозволяють відволікатися на рутину лише в разі відхилень.

У суперечці народжується істина... але іноді помирає здоровий глузд.

Важливо вміти сперечатися. Точніше, вести діалог. Відстоювати свою правоту важливо й потрібно. Але це треба вміти робити. Не потрібно битися на смерть. Не потрібно зайвих емоцій. Це лише твої колеги, партнери... І повір: більшість питань, про які ви сперечаєтеся, не варті зіпсованих стосунків із людьми.

Мінімальний життєздатний продукт (minimum viable product, MVP) — продукт із мінімальними, але достатніми для задоволення потреб перших споживачів функціями

Зараз дуже багато статей на цю тему. Більшість присвячено стартапам і продуктовим ІТ-компаніям.

Але MVP — дуже корисна річ у розробці загалом.

Тут я поділюся досвідом застосування MVP у сервісних підрозділах розробки компаній поза ІТ-галуззю.

Отже, у нас є розробник, а можливо, і не один.

Ви їхній керівник.

Вони на окладі, і у вас не болить голова, чим виплатити їм зарплату наприкінці місяця.

І у вас є замовники. Внутрішні, але від цього не менш важливі й улюблені :-)

І одного разу в когось у компанії виникає думка: а розробімо продукт X.

Отже, бажання замовника є, він має повноваження й готовий працювати. 

Поїхали.

Працювати з людьми — найскладніше. Принаймні для мене.

Намагатися оберігати їх від проблем, які їх не стосуються. Фільтрувати зовнішні впливи. Бути батьком для солдатів, як рекомендує Р. Ґандапас, і водночас не дозволяти «пересаджувати мавпу» собі на плечі щоразу, коли виникає проблема...

Заохочувати ініціативність і самостійність, але не дозволяти їм перетворюватися на самоуправство та нехлюйство.

У моїх командах завжди багато професіоналів. У своїх сферах вони на 200% розумілися краще за мене: розумні й самодостатні працівники. Тому вмикати начальника найчастіше не виходило. Доводилося шукати рішення й виробляти способи поведінки: втрата людини в проєкті — завжди зайвий головний біль, якого ніхто не потребує.

Нижче — кілька моїх правил і принципів, напрацьованих досвідом.