Роман про DevOps
Ця книга – історія одного вигаданого підприємства, свого роду виробничий роман. На цьому прикладі автори книги постаралися показати, чому так важливо, щоб у компанії айтішники активно взаємодіяли зі співробітниками решти відділів, і як правильно організувати таку співпрацю. Автори, фахівці та консультанти з IT-менеджменту орієнтуються на управлінські методи DevOps, Agile, Continuous delivery, виробничу систему Toyota. DevOps – основний метод, який описується в книзі, передбачає максимально активну взаємодію в компанії фахівців з IT-розробки зі спеціалістами з IT-обслуговування, взаємну інтеграцію їх робочих процесів. Ефективна розробка та експлуатація програмного забезпечення та вся робота IT-сектору неможлива без співпраці IT-фахівців з усіма іншими підрозділами компанії. Відсутність грамотного IT-менеджменту веде до того що, що IT-сектор виявляється похований під завалами різнорідних завдань, що з усіх відділів компанії, що призводить до накопичення величезного технічного боргу і зрештою зовсім паралізує роботу.
Наша історія почалася одного вересневого ранку, коли Білл Палмер, керівник невеликої IT-групи в компанії Parts Unlimited, як завжди, їхав на роботу. Але раптом його звичні роздуми про повсякденні справи перервав дзвінок із відділу кадрів із проханням терміново зайти. Як з’ясувалося, Білла викликає до себе генеральний директор (CEO) Стів Мастерс, який вирішив поставити його на чолі всього ІТ-сектору.
Parts Unlimited — великий виробник автозапчастин та комплектуючих, компанія з довгою історією, що сягає корінням у 1920-і роки. Положення її на ринку останнім часом незавидне. Конкуренти обходять Parts Unlimited у всіх областях, обсяг продажів знизився, впровадження нових технологій йде з великим скрипом, штат скорочується. Подейкують навіть про розформування деяких підрозділів.
У спробі вдихнути у Parts Unlimited нове життя кілька років тому було розроблено проект «Фенікс» — створення спільної платформи для всіх замовлень, оформлених як у магазинах, так і через інтернет. Але «Фенікс» теж буксує: час його впровадження давно перевищив усі терміни, а вартість сильно вийшла за межі бюджету. Основний проповідник “Фенікса” – комерційний віце-президент Сара Моултон, один з основних помічників Стіва, який дозволив їй залучати всі доступні ресурси.
Структура Parts Unlimited
• Правління (CEO, рада директорів)
• Виробництво (заводи, складальні лінії)
• Мережа розподілу продукції (магазини, склади, доставка)
• Бізнес-сектор (бухгалтерія, відділи фінансів, маркетингу, продажу, аналітики)
• IT-сектор (розробка ПЗ) , IT-обслуговування, інформаційна безпека)
У IT-секторі відділ IT-обслуговування (IT Operations) займається обслуговуванням програмного забезпечення та комп’ютерів у всіх підрозділах Parts Unlimited. Такі відділи є сьогодні у більшості компаній. Їхні співробітники — системні адміністратори та оператори підтримки користувачів. Відділ розробки ПЗ (IT Development) створює на замовлення топ-менеджменту нові програми та тестує їх, а потім передає в IT-обслуговування для розгортання в реальному робочому середовищі. Відділ інформаційної безпеки (InfoSec) слідкує за дотриманням правил безпеки IT.
Злети і падіння
Нова посада та нові проблеми
У Parts Unlimited директори з інформаційних технологій (CIO) постійно звільнялися. Ходив навіть жарт про те, що призначення на посаду CIO – це кінець кар’єри. На цей раз компанія залишилася не лише без CIO, а й без начальника IT Operations.
Білл Палмер розумів всю складність роботи в IT-обслуговуванні: навіть йому, керівнику невеликого колективу, доводилося постійно вислуховувати скарги про збої в мережі та непрацюючі комп’ютери. Він хотів відмовитися від підвищення, але Стів, вміло керуючи бесідою і згадавши попередні заслуги та армійське минуле Білла, змусив його мимоволі погодитись. Та й збільшення зарплати не завадило б Біллу, адже вони з дружиною все ще не виплатили кредит за будинок і виховують двох синів.
Привітавши Білла з підвищенням, Стів одразу кидає його на передову — стався черговий «збій першого рівня»: впала програма розрахунку зарплати, а перерахувати людям гроші потрібно сьогодні до п’ятої вечора. Якщо цього не зробити, компанія порушить норми трудового законодавства, профспілки зчинять галас, почнуться перевірки і репутація Parts Unlimited зіпсується остаточно.
Перші кроки: хаос і плутанина
Прибігши до фінансового відділу, Білл застає там повний хаос: співробітники вручну перераховують відомості та вносять дані в поспіхом зроблену програму коригування, яку їм надіслали розробники в обхід IT-обслуговування. Виявляється, всі дані про погодинну роботу обнулилися, а замість даних про працівників у деяких полях спливають символи, що не читаються.
Білл каже керівництву, що намагатиметься зробити все можливе, але радить підготуватися до плану Б: провести виплати за платіжними відомостями минулого місяця. Але тоді може виявитися, що комусь виплатять не ту суму, нові співробітники залишаться без зарплати, а тим, хто звільниться, заплатять зайві гроші, які доведеться потім повертати. До того ж на носі фінансова перевірка, і за такі фокуси дуже не поздоровиться головним бухгалтерам та фінансовому директору Діку Лендрі.
Білл повертається до своєї будівлі — одна з найстаріших і найнедоглянутіших у компанії, що ніби натякає на пріоритети. У мережному операційному центрі він застає своїх колишніх колег, а тепер підлеглих: Уеса, начальника відділу розподілених операцій, та Патті, начальника сервісної підтримки. Разом з іншими співробітниками вони на підвищених тонах обговорюють падіння мережі зберігання даних (SAN). Виявляється, минулого вечора повідомлення про збій у системі зарплат надійшло під час оновлення SAN. Провідний інженер Уеса, незамінний Брент, припустив, що SAN пошкодив дані, і запропонував відкотити оновлення. Після цього вже не працювало.
Швидко повідомивши Уесу та Патті про свій новий статус (Стів так і не спромігся офіційно повідомити всіх про призначення), Білл включається в роботу. Довелося знову викликати всезнаючого Брента, відриваючи його від роботи над “Фенікс”.
В результаті довгих і болісних пошуків з’ясувалося, що один із розробників «по-швидкому» встановив додаток-анонімайзер 1 на прохання начальника відділу інформаційної безпеки Джона Пеша, після чого поїхав у відпустку. І справді «кракозябри» з’являлися лише в тих полях, де було вказано персональні дані робітників компанії, безпека яких, на думку Джона, була під загрозою.
Білл дуже серйозно розмовляє з Джоном, якого сприймає виключно як перешкоду. Усі в IT-обслуговуванні звикли вважати «безпечників» параноїками, які збожеволіли на абсурдних правилах і лише змушують усіх робити зайву роботу. Джон стверджує, що намагався на благо компанії, адже незабаром на підході ще й аудит безпеки. Якщо аудитори виявлять «дірки», як вже бувало неодноразово, це загрожує Parts Unlimited величезними штрафами. Оскільки в IT Operations місяцями не реагували на його прохання, він вирішив встановити сторонню програму шифрування персональних даних, «абсолютно надійну», за запевненнями виробника. На питання Білла, чи тестував він програму, Джон відповідає, що ні, тому що він не має відповідного середовища для тестування.
На довершення всіх бід робочий ноутбук Білла зависає при черговому оновленні корпоративної системи, і Патті надає йому допотопного монстра з приклеєним акумулятором скотчем – типова ситуація «шевця без чобіт». Черга заміни обладнання теж давня проблема їхнього відділу.
Поки Білл, Вес і Патті обговорюють, як швидше виправити збій, Брент напружено клацає по клавіатурі і повідомляє, що виправив програму. Начебто криза вирішена, але час виплат минув, бухгалтерія скористалася поганим планом Б, а наступного дня в газетах написали про черговий провал Parts Unlimited.
Спроби все організувати та нові кризи
Білла дуже стурбував той факт, що ніхто в компанії не контролює численні зміни в чинному програмному забезпеченні. На спільній нараді ІТ-сектору він наказав створити систему моніторингу всіх змін. Патті сказала, що вона вже кілька років намагається впровадити систему моніторингу патчів та правок, але безуспішно. Люди все одно діють в обхід, або вважаючи зміни незначними, або на екстрене прохання співробітників інших відділів.
Заглибившись у цю систему, Білл розуміє, що вона до того ж катастрофічно незручна. Тоді Білл роздає паперові картки та просить присутніх написати всі майбутні зміни та їхню гадану дату, після чого принести ці картки Патті, яка з двома співробітниками має продумати нову схему. За кілька днів з’ясовується, що таких змін майже 450, а картками завалено кілька столів.
Крім роботи у своєму відділі Білл бере участь у регулярних нарадах з приводу проекту “Фенікс”. Комерційний директор Сара дуже незадоволена тим, що Білл відволікає цінного співробітника Брента від її проекту і не бажає чути виправдання. Начальник розробників Кріс стверджує, що якщо все піде як слід і віртуальне середовище, створене за сприяння Брента, працюватиме добре, то проект можна запустити за тиждень. Почувши це, Білл жахається. Вони з Уес обурено міркують про те, що розробники вічно тягнуть до останнього, немов весь графік проекту придуманий тільки для них, а потім систему потрібно ще впроваджувати IT-обслуговування . Як завжди, виникнуть непередбачені ускладнення, нестача серверів, затримки, перешкоди, переробки коду та конфлікти неузгоджених версій.
Білл намагається відмовити Стіва від застосування «Фенікса», але той теж не хоче чути про це, адже він уже виступив перед членами правління і навіть дав інтерв’ю ЗМІ про майбутні зміни в сервісах компанії. Якщо зміни будуть в черговий раз відкладені, то інвесторам це не сподобається і становище Parts Unlimited стане дуже плачевним.
Тим часом, глава внутрішнього аудиту Ненсі повідомляє Біллу про майбутню перевірку і про те, що потрібно усунути цілий список проблем, що займає в роздруківці сотню аркушів дрібним шрифтом. Це означає, що потрібно виділити якусь частину співробітників на потреби аудиту, адже вони й так зайняті по горло. Деякі сервери програм обліку дуже старі, і розуміється на їхній роботі лише «найдосвідченіший інженер» Брент. Знову цей Брент!
Білл виділяє час, щоб простежити за робочим процесом Брента. Виявляється, той завжди зайнятий і нічого не встигає, його перекидають з однієї ділянки на іншу, та ще й дзвонять з дрібних питань, хоча, наприклад, з переустановкою операційної системи впорався б і рядовий співробітник. Загалом те саме можна сказати і про весь відділ IT-обслуговування. Як каже Патті, пріоритет завдань тут встановлюється лише тим, хто сильніше накриє. Білл подумує про якусь систему розподілу роботи, але йому мало що спадає на думку. Він просить Патті підготувати список всіх проектів, покладених на їхніх ключових співробітників, щоб розрахувати їхнє навантаження і, можливо, попросити Стіва про розширення штату. В результаті зовнішніх і внутрішніх проектів виявляється чи не півтори сотні, і всі вимагають ресурсів чи не на найближчий рік, хоча виконати їх треба за кілька місяців.
Нові знайомства та нові рішення
Сумні роздуми Білла перериває виклик на зустріч із передбачуваним майбутнім членом правління Еріком Рейдом, який здається трохи загадковою та дивною людиною. Ерік пропонує Біллу проїхатися до виробничої будівлі, де вони спостерігають за перетворенням сировини на продукцію, що відправляється на склади, тобто за так званим потоком створення цінності. Зважаючи на те, як Ерік докладно розповідає про труднощі виробництва в минулому, колись він брав у цьому безпосередню участь. Він розмірковує про колишній безсистемний набір замовлень, про скупчення матеріалів у вузьких місцях (так званих пляшкових шийках), через що страждав на темп всього виробництва, і про те, як менеджери вирішували подібні проблеми.
За словами Еріка, ефективними виявилися три методи: налагодження швидкого потоку роботи, скорочення та посилення циклу зворотного зв’язку та культура постійного експерименту та навчання . Спочатку порівняння матеріального виробничого процесу з інтелектуальною діяльністю в ІТ здивувало Білла, але потім він потроху почав вникати в це порівняння. І справді сировиною тут можуть бути ПЗ, серверні потужності, ліцензії та замовлення, а продукцією — кінцевий стан системи. Наприкінці бесіди Ерік запропонував Біллу задуматися про чотири типи роботи у своєму відділі та зателефонувати, як тільки той буде готовий.
Білл з Патті продовжують працювати над системою обліку змін та їх формалізації. Вони ділять їх за ступенем серйозності, рутинності та необхідності. Непріоритетні зміни вирушають у кінець черги, для рутинних пропонується розробити стандартні механізми, щоб наступного разу займали менше часу 2 . Наради щодо змін пропонується зробити регулярними, а процес відстежувати їх по дошці канбан, розділеної на графи «Заплановано», «У роботі» та «Зроблено», із зазначенням найкращого часу з урахуванням завантаження проектами. Крім того, пропонується проводити регулярні навчання зі збоїв та виявлення змін, які до них призвели.
«Незамінному» Бренту (а по суті, пляшковому шийку) Білл наказує зосередитися лише на проекті «Фенікс» і на екстрених випадках, не відволікаючись на жодні інші питання. Разом з Патті та Уесом вони замислюються над тим, як замінити Брента в інших справах. Для цього вони вирішують стежити за тим, як Брент «інтуїтивно» розплутує проблеми, і складатиме протокол його дій. Окрема команда повинна розбиратися з екстреними випадками та кликати на допомогу Брента лише у найскладніших, намагаючись запам’ятовувати, що він робив, і тим самим навчаючись. Щоправда, виявляється, що частина запланованих змін відкладається через відсутність Брента, а це загрожує накопиченням нових проблем.
Крах «Фенікса»
У призначений день розгортання Фенікса з тріском провалилося. При впровадженні коду навантаження на сервери різко збільшилося, і розгортання сповільнилося. Співробітники Кріса та співробітники Білла постійно лаялися між собою через непорозуміння та відсутність чіткої документації. В результаті бази даних онлайн-замовлень та замовлень у магазинах не погоджувалися, а система касових терміналів повністю зависла. Невдоволені замовники розривали контракти, продавці вдавалися до екстрених заходів — виписували відкладені чеки картами, передаючи персональні дані небезпечними каналами. Це призвело до чергової загрози безпеці інформації (щоправда, Джон тут несподівано допоміг Біллу, коли відволік аудиторів від кімнати, де спішно знищували скани карт з CVV2-кодами). Члени правління були люті, інвестори розчаровувалися. Знову виникла загроза поділу компанії та передачі IT-сектору на аутсорсинг. Для виправлення ситуації Стів надав усім три місяці.
Перші проблиски і знову хмари
Після пережитого Білл та Кріс (відділ розробки) вирішують поговорити до душі в барі. Вони діляться своїми думками та занепокоєнням, домовляючись про більш тісне співробітництво надалі.
Тим часом, система обліку змін дає свої перші плоди: вдається виявити випадки дублювання змін, внесених різними відділами. Але ж вона виявляє і катастрофічний вплив аврального впровадження «Фенікса» — сотні запланованих змін так і не виконані. У результаті Білл остаточно встановлює чотири типи роботи у відділі IT-обслуговування:
• бізнес-проекти (за дорученням інших відділів компанії);
• внутрішні проекти;
• зміни;
• незаплановані ситуації (збої, аврали).
Причому потрібно прагнути до того, щоб останній тип якнайменше впливав на перші три.
Під час чергового «збою першого рівня» (несправності системи виставлення рахунків) IT-команда діє вже впевненіше, підтримуючи зв’язок з іншими відділами і виявляючи, які зміни могли спричинити збій. Ніхто не кричить і не звинувачує інших, а Білл навіть має час провести вечір із сім’єю. Брента він теж відпускає додому, щоб той своїми «інтуїтивними» діями не зробив гірше і щоб він прийшов лише тоді, коли джерело збою буде локалізоване. Але тут Біллу посеред ночі дзвонить Стів і на підвищених тонах наказує терміново повернутися на роботу і привести з собою всіх «ледачих» співробітників. Жодні пояснення про те, що робота йде в штатному режимі, він вислуховувати не бажає. Білл теж виходить із себе, заявляє про свій відхід і вішає слухавку.
Корінні зміни
Через кілька днів, проведених з дружиною та дітьми, Білл погоджується поговорити зі Стівом, який просить вибачення і пропонує Біллу попрацювати ще хоча б три наступні місяці в «атмосфері довіри, відкритості та співпраці». Він зрозумів, що IT – це не просто відділ, а серцевина кожного зусилля компанії, критично важлива для всіх щоденних операцій. Білл погоджується і бере участь у неформальній зустрічі глав усіх ключових відділів, де всі вони слідом за Стівом діляться своїми думками, переживаннями і мріями.
Метод перший. Налагодження процесу
Переходячи до технічних питань, Білл міркує про те, що IT-обслуговування бере в роботу проекти, незалежно від ступеня їх важливості та можливості виконання. Внаслідок цього утворюється «технічний борг», і всі зусилля відділу витрачаються лише на виплату «відсотків у вигляді незапланованої роботи». Щоб розібратися з купою поточних завдань, спочатку було запропоновано оголосити заморожування всіх IT-проектів, крім «Фенікса» та частини внутрішніх. Це знизило завантаження співробітників, але Білл побоювався, що вона знову зросте після скасування заморозки, тож довелося розробити процес категоризації проектів. За аналогією з промисловим виробництвом було вирішено розподіляти роботу по «робочим центрам» із кількох осіб. Кількість бізнес-проектів, що перебувають у роботі (wip — work in progress), не повинна перевищувати 4–5 одночасно, плюс 20% від загального обсягу мають займати внутрішні роботи (заміна інфраструктури, обслуговування баз даних, безпека тощо). Інші проекти залишаються як би на «вхідному складі», чекаючи своєї черги; деякі з них, як оновлення версій баз даних, які все одно заплановано списувати через рік, передбачається і зовсім скасовувати. Потрібно навчитися відмовлятися від виконання свідомо нездійсненних та необов’язкових проектів. Важливо зрозуміти, що кількість ресурсів та людино-годин у відділі обмежена, він в одиницю часу може пропускати через себе лише певну кількість wip, і ніяка мультизадачність це не змінить. Основний висновок полягав у тому, що удосконалення на будь-яких ділянках, крім пляшкового шийки (а таким був як весь відділ IT-обслуговування в цілому, так і Брент зокрема), — це ілюзія .
Концепція зайнятості також була переглянута, коли «проста» робота, яку Брент припускав виконати за півгодини, розтягнулася на кілька днів, оскільки вимагала погоджень з іншими співробітниками, зайнятими іншими проектами. Так було зроблено ще один важливий висновок — для більш швидкого функціонування системи співробітники повинні мати певний «холостий час» на випадок суміжної та незапланованої роботи, інакше вона теж лише накопичуватиметься на «вхідному складі». Автори стверджують, що якщо зайнятість співробітників постійно перевищує 80%, час очікування різко збільшується .
Зрозуміло, всі проекти відслідковувалися по канбан-системі, а багато процесів стандартизувалися для їх швидшого подальшого виконання та виконання подібних завдань в інших проектах. Завдяки скасуванням мультизадачності та зосередженню на малій кількості дійсно важливих проектів за тиждень відділу вдалося виконати більше, ніж він зазвичай виконував за місяць. А завдяки покращеній системі моніторингу та контролю вдалося виявляти потенційні випадки порушення безпеки, тож необхідність впровадження нових протоколів, на якому наполягав Джон (InfoSec), виявилася не такою вже нагальною. Спочатку Джон ображався, що його вважають зайвою ланкою, але згодом став активно співпрацювати з Біллом.
Але це був лише перший із трьох запропонованих Еріком Рейдом методів. Недостатньо просто стандартизувати та оптимізувати процес обробки поточної роботи чи потоку створення цінності. Потрібно було також простежити, щоб не було руху проти потоку (наприклад, відправок коду на переробку та появи незапланованої роботи), а також за тим, щоб враховувалася загальна ситуація компанії. Керівник відділу повинен мислити подібно до головного керівника компанії, орієнтуватися на загальні цілі, співпрацювати з іншими відділами, підтримуючи при цьому атмосферу експериментування та навчання.
Метод другий. Посилення зворотного зв’язку
Разом з Джоном Білл зустрівся з керівниками основних відділів, розпитав про їхню роботу і подивився на компанію їхніми очима. Особливо йому допомогла розмова з фінансовим директором Діком Лендрі, який неформально виконував роль виконавчого директора (COO). Дік сказав: хоч його і хвилюють фінансові показники, ринкова частка та прибутковість, але це не найголовніше. Головне — це розуміння потреб клієнтів, правильний портфель продукції, швидкість виходу ринку, конкурентоспроможність і точність прогнозів продажів, тобто ширша перспектива. Що користь у відмінних фінансових показниках на неправильному ринку з неправильною стратегією та неправильною дослідницькою командою? Озброївшись цим знанням, Білл спробував усвідомити роботу свого IT-відділу з цієї широкої точки зору і побачив взаємозв’язок із ним усіх служб. З розмов з керівниками відділів він краще зрозумів, що їм потрібно від IT (наприклад, ефективніша система відстеження товарів та завантаження складів). Поділившись своїми проблемами, Білл заручився їхньою підтримкою у питанні виділення додаткових фондів для IT. Водночас він зрозумів, що амбітний «Фенікс», розробка якого триває вже три роки, не вирішить жодної з цих проблем. Потрібні дії, які приносять хоча б невелику віддачу набагато швидше і дозволяють своєчасно реагувати на запити ринку.
Метод третій. Експерименти
І ось настала нагода приступити до подібного проекту. Сара в черговий раз вирішила в обхід IT-розробників і замороженого IT-обслуговування пропхати свій спосіб збору даних для «Фенікса», передавши його на аутсорсинг. В результаті виник збій, який завдяки регулярним тренуванням та покращеній системі моніторингу вдалося цього разу вчасно усунути. На нараді Білл запропонував створити окрему оперативну команду для розробки маркетингових акцій на День подяки та «чорну п’ятницю». До цієї команди увійшли представники відділу IT-розробки, IT-обслуговування та бізнес-відділів, а проект отримав назву «Єдиноріг» і був так званим конвеєром розгортання від розробки коду до його впровадження.
Учасники проекту розрахували, що потрібно кожному відділу для реалізації своєї функції, визначили точки перетину (створення середовища, автоматичні тести, запуск коду, перенесення в інше середовище, контроль якості) та розробили для них стандартні процедури. Так зменшилася роль супровідної документації, а розробники змогли робити пакети для автоматичного розгортання коду в тестовому та робочому середовищі без ручного контролю тестувальників та IT-обслуговування. Перейшовши на хмарні робочі сервіси і позбавившись зайвої рутини, IT-обслуговування передало свої сервери розробникам для створення більш реалістичного середовища. А щоби спочатку захищати дані користувачів, вони залучили і людей з відділу Джона. Усі домовилися регулярно зустрічатися на робочих нарадах та координувати свої дії.
Незважаючи на труднощі, що виникали в процесі розробки додатків для онлайн-рекомендацій, онлайн-замовлень, зберігання інформації про продукцію та її доставку, проект «Єдиноріг» вперше за півтора роки дозволив компанії закінчити квартал з позитивними показниками, а натхненні працівники оперативної команди поставили собі за мету довести кількість невеликих релізів до кількох десятків на день, як це робиться у провідних високотехнологічних компаніях, хоча раніше їм здавалася нездійсненною мрія і про тритижневі релізи. Автоматизувавши рутину і звільнивши таким чином час, вони почали іноді спеціально запускати шкідливі програми у симуляції робочого середовища для виявлення потенційних збоїв та регулярно проводити тренування з їх виправлення.
Ерік Рейд зізнається Біллу, що він спеціально спостерігав за ним і наставляв його на істинний шлях, тому що займається підтримкою інновацій у сфері IT-менеджменту і проповідує нові методи, такі як DevOps, Agile, Continuous deployment та адаптацію виробничої системи Toyota. Від ідеї стати членом правління він відмовився і вирішив створити хедж-фонд для підтримки найкращих умів у IT-сфері.
На новорічній вечірці Біллу подарували покритий бронзовою фарбою його старий ноутбук-монстр, а Стів запропонував йому дворічний випробувальний термін, щоб попрацювати начальником різних відділів і за три роки зайняти місце виконавчого директора Parts Unlimited. На його думку, посади ІТ-директора Біллу буде недостатньо. IT-сектор — кров і серце будь-якої компанії, і, якщо людина в ньому не розуміється, вона не зможе стати добрим керівником. Білл пройшов цю школу і здатний рухатися далі.
10 найкращих думок
1. Інформаційні технології у сучасній бізнес-структурі відіграють провідну роль. Активна взаємодія фахівців IT між собою та з представниками інших відділів дозволяє швидше реагувати на ситуацію та впевнено контролювати процеси виробництва та управління.
2. Робочий процес в IT-відділі подібний до виробничого процесу на фабриці , тільки сировина тут — програмний код, операційні системи, ліцензії, серверні та обчислювальні потужності, професійні навички, а продукція — працююче ПЗ та виконані завдання інших відділів.
3. Робота в IT-відділі ділиться на чотири типи: бізнес-проекти (виражають потреби інших відділів та адміністрації), внутрішні проекти (обслуговування серверів та інфраструктури), зміни (правки чинного ПЗ у міру необхідності) та незапланована робота (усунення помилок, збоїв) , несправностей).
4. Пропускна здатність IT-відділу обмежена. Взявивши на себе надто багато роботи, він створює «технічний обов’язок» у вигляді незапланованої роботи.
5. Перший спосіб оптимізації: оптимізація робочого процесу завдяки системі моніторингу змін та автоматизації завдань, моніторингу робочого процесу (канбан-дошки) , а також виявлення та ліквідації пляшкового шийки — найвужчої ділянки.
6. «Робочим центрам», тобто групам співробітників, потрібно мати вільний час, тому що до них при виконанні своїх завдань можуть звертатися інші «робочі центри» та співробітники, тим самим накопичуючи «технічний обов’язок».
7. Другий спосіб: скорочення та посилення зворотного зв’язку. Заморожування надходження нових завдань за необхідності ліквідації пляшкового шийки та «технічного обов’язку»; створення автоматичних систем тестування та розгортання; інтеграція завдань відділу розробки та відділу обслуговування; усвідомлення загальних цілей підприємства.
8. Для своєчасного реагування на ринкову ситуацію цикли релізів нового продукту мають скорочуватися. Краще ділити роботу на частини меншого обсягу, які можна швидше обробляти та впроваджувати.
9. Третій метод: підтримка культури, що заохочує експериментування та навчання; створення атмосфери довіри та відкритості; вміння брати він усвідомлені ризики.
10. Третій спосіб також передбачає регулярні тренування щодо усунення можливих збоїв та використання шкідливих програм для перевірки стабільності систем.
1 . У цьому випадку додаток, який приховує персональні дані
2 . Канбан-дошка – інструмент у рамках планування завдань за системою канбан. До дошки кріплять картки з описом завдань і в міру виконання етапів завдання переклеюють з однієї колонки до іншої