Чи не контролюються процеси моєї команди?

Я керівник команди програмного забезпечення розробників (нещодавно я взяв під контроль нову команду) і в кінцевому рахунку відповідальний за підтримку високої продуктивності, хорошої якості та організованих пріоритетів.

У моїй команді є 6 старших розробників, але тут тут все безладно. Ситуація полягає в тому, що мені доводиться вирішувати запити JIRA приблизно з 10 різних контактних точок в нашій компанії, і всі вони представляють різні бізнес-підрозділи або клієнтів.

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

Які хороші способи впоратися з цим? У мене є багато теорій, але я шукаю відповідь у того, хто насправді має досвід роботи в такій ситуації, як моя.

Ось невеликий список того, як все працює:

• Кожен розробник несе відповідальність за конкретну програму та послуги, що взаємодіють з нею;
• Випуски, як правило, перевіряються клієнтом на модельованому виробничому сервері, а потім розгортаються на реальному сервері;
• Кожну програму використовують в середньому 50-80 осіб, загалом 8 програм.

Спасибі

наші клієнти не приймуть раптової затримки результатів

Ну, тоді їм доведеться сприймати низьку якість, яку вони отримують.

Що ви повинні зробити для того, щоб це змінити - це змусити своїх клієнтів сприймати реальність розробки програмного забезпечення (або будь-якого іншого виробництва!): Те, що поспішає, впливає на якість.

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

Знайдіть ключових зацікавлених сторін у приміщенні та скажіть: "Ви хочете, щоб виправити X, чи ви хочете, щоб Y було доставлено? У нас є лише час для одного з двох". Покладіть на них відповідальність за встановлення пріоритетів і зрозумійте, що ви обмежені. Якщо вони вимагають чогось нового, запитайте у них, що вони готові пожертвувати за допомогою своєї поточної дорожньої карти для досягнення цього.

Запитайте свою команду, який час та ресурси їм потрібні, щоб "виправити все правильно" (як з точки зору виправлення основних помилок, так і з точки зору виправлення більших проблем у якості коду / архітектурі / тощо). Включіть ці елементи до списку речей, яким ваші зацікавлені сторони мають розставити пріоритет.

Найкраще, що я коли-небудь робив у моїй нинішній роботі, було одночасно потрапити до 8 найкращих зацікавлених сторін у кімнаті та скласти купу 16 індексних карток, що представляють нові функції, про які вимагали. Я відступив від столу і сказав: "Ми можемо доставити один із них за один раз. Яке замовлення ви бажаєте?" Нехай вони обговорюють один одного над бізнес - пріоритетом , а не ви застрягли в середині.

Зупиніться, опустіть і скочіть. Пожежам потрібне паливо і часто воно надходить у вигляді паніки. Виділіть час, щоб керувати собою та командою в порядку. Оцініть своїх розробників і перевірте, чи є у вас недостатньо кваліфіковані та / або недостатньо працюють, щоб отримати потрібні результати. Вирішіть, хто залишається (і докладіть зусиль, щоб їх утримати), кому потрібно трохи натиснути, решта повинні йти. Оцініть підтримку та інструменти, які отримують ваші програмісти, щоб переконатися, що вони можуть виконувати свою роботу. Переконайтесь, що дотримуються тестування звуку, огляду, контролю джерела та документації. Хороші люди з хорошими інструментами повинні бути відповідальними, щоб робити добру справу.

Повинна існувати система, яка б знала, що потрібно робити вашій команді, над чим зараз працює і коли вони очікують її завершення. Багато методологій, теорій, програмного забезпечення, сухих дощок для стирання та наліпок, документів та електронних листів для цього. Зробіть щось робочим, змусивши всіх дотримуватися цього. Якщо кожен має певний внесок у систему, є більше стимулів дотримуватися її.

Отримати краще розуміння того, що очікують клієнти. Це може не бути частиною вашої роботи. Можуть бути й інші люди, які роблять вигляд, що їх волосся загоряються, їхні клієнти нещасні і небо падає. Це те, що вони роблять, а деякі справді добре в цьому. Якщо все є надзвичайною ситуацією, то нічого не є надзвичайною ситуацією, тому що це не все буде виконано. Пропонуйте посидіти на дискусіях з клієнтами випадково. Ви побачите, що багато людей, які приємно мати, перетворюються на «порушників угод», коли вони потрапляють до команди розробників. Будьте технічною службою або іншим приводом, щоб допомогти. Обіцяння, які ви не можете дотримати, гірше, ніж сповіщати їм, що вони не хочуть чути в першу чергу. Ми хочемо зробити гарну роботу, тому нам потрібно 8 тижнів, а не 5. Вони будуть щасливішими з часом.

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

Вам потрібно пояснити, що при кращих процесах, поки доставка нового програмного забезпечення буде затримана на невелику суму, буде менше помилок (ніколи не буде нуля). Якщо ви зможете домовитись, що це шлях вперед, ви зможете почати впроваджувати процеси, необхідні для відновлення контролю над своєю розробкою.

Використання Agile процесу може допомогти тут, оскільки вони пропонують (і в деякому мандаті на впровадження), щоб замовник був включений до складу команди. Якщо ви дуже тісно залучаєте клієнтів, вони побачать, що працює і що ви можете зробити з перших рук.

Моя думка (обмежений досвід): Я думаю, що потрібно вирішити дві проблеми. По-перше, процес якості. Ви використовуєте scrum / водоспад / щось середнє? У scrum можна додати додаткові завдання для кожної історії: 1 придумати тестовий сценарій / план, інший для запуску, інший для огляду коду тощо. У водоспаді ви можете просто додати ці кроки?

Інша проблема - це основна проблема, яка існує повсюдно в програмному забезпеченні. Управління очікуваннями. Тобто збільшується час від того, хто кричить, що їм потрібна кнопка, щоб зробити X, щоб його доставити.

Якщо ви можете додати додаткові кроки до процесу та зробити великий про це фанфаре [ми зараз реалізуємо цей якісний процес: це означатиме менше часу на виправлення помилок! та якісніші результати! велика електронна пошта / зустрічі тощо, щоб повідомити їм], і регулярно надавати результати (ala scrum). Ідея полягає в тому, щоб ті, кому ви доставляєте, дізнатись і побачити цінність у додаткових кроках процесу, і вони будуть купувати їх. Менше часу виправлення помилок = більше часу на реалізацію та тестування функцій.

Клієнти не приймуть раптової затримки результатів? Вони в значній мірі повинні. Зрозуміло, що не може продовжуватись так, як є. Можливо, ви можете додати додаткові етапи забезпечення якості, а потім, якщо потрібно, додати більше членів команди? Але якісні кроки абсолютно необхідні.

Знову ж таки, якщо ви використовуєте scrum або подібне, ви можете націлитись на тижневий спринт, тому регулярно проводяться результати. Це сподобається людям так само, як і швидкий поворот.

Сподіваюся, що це допоможе певною мірою. Сподіваюся, я не пропустив суть.

Те, що ви описали, звучить дуже нормально і зовсім не дуже тривожно.

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

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