Тихий криза в розробці софта



Про мене
Я працюю в сфері розробки програмного забезпечення 28 років. Моя нинішня посада — старший директор з розвитку програмного забезпечення консалтингової компанії в Остіні, штат Техас. Я працюю на цій посаді трохи більше шести років.

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

У Всесвіті працює досить жорстокий вид карми.

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

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

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

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

Будьте обережні з високими показниками
Безумовно, ви вирішили, що деякі розробники у вашій команді відмінні виконавці. Це зазвичай ті розробники, які працюють швидко. Менеджери зазвичай вибирають і воліють цих розробників проектів.

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

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

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

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

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

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

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

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

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

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

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

Це помилкова економія. Вашим співробітникам подобається працювати на вас — вірно? — значить, оборот повинен бути низьким. Не враховувати той факт, що розробники можуть піти значить розглядати нестандартний сценарій можливих подій. Щоб добитись кращих результатів, треба розглядати стандартний сценарій.

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

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

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

Ці розробники ваші справжні лідери. Його або її колеги вже виконали важку роботу виявлення справжніх лідерів за вас. Ці лідери мають бути визнані такими і вимагають спеціального розгляду.

Перш за все, пам'ятайте, що бути і розробником програмного забезпечення і лідером складно і займає багато часу. Розробка програмного забезпечення вимагає концентрації — концентрації, яка легко втрачається після одного питання або десяти хвилин біля дошки. Повернутися на потрібний лад після цього буває проблематично. Чекайте, що у ваших лідерів буде йти більше часу на завершення своїх проектів — в кінці кінців, вони роблять відразу дві роботи.

Ці лідери також повинні бути публічно визнані такими. Їх потрібно заохочувати за роботу, яку вони роблять. Так їм легше допомагати іншим розробникам без образ — це тепер частина їх офіційного опису професії! — і вона забезпечує їм визнання, а це піднімає бойовий дух. Без цього офіційного визнання, надання допомоги часто може здаватися їм просто небажаним тягарем. Не дозволяйте цьому статися.

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

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

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

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

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

Наприклад, розглянемо проект розробника#1, який ймовірно буде виконаний за 10 днів без помилок або з малою кількістю помилок) і проект розробника#2, який ймовірно буде закінчено через 5 днів, але у підсумку в ньому будуть виявлені 4 помилки і на їх виправлення кожної піде за 2 дні. І все це без урахування додаткових витрат на підтримку і негативний досвід клієнта в результаті цих помилок.

В такому випадку розробник#1 зробив тільки одну роботу за 10 днів, а розробник#2 п'ять (сам проект + виправлення 4 помилок) за 13 днів. Хто з них більш продуктивний? Ваша система показників, очевидно, бреше вам. Не довіряйте їй і ні в якому разі її не афішуйте.

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

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

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

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

Іноді виникає проект, в якому потрібна тісна співпраця. У більшості офісів є конференц-зали, які можуть бути тимчасово перепрофільовані під відкриті офісні простору.

Заохочуйте експерименти
Ми всі чули про знаменитого 20% часу Google, завдяки якому стало можливе існування Gmail, і все це переросло в успішний онлайн бізнес по розробці додатків.
У той час як у більшості компаній немає величезних грошових ресурсів, щоб дійсно реалізувати політику 20%, експерименти, тим не менш, періодично слід заохочувати і підтримувати. Розробники програмного забезпечення не позбавлені хороших ідей і мають особливий досвід, а відповідно у них хороше чуття стосовно програм, які можуть бути поліпшені і розширені.

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

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

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

Ніколи не відхиляйте невеликі прохання
Ваш співробітник хоче монітор побільше? Купіть йому один. Вони хочуть певну клавіатуру? Купіть. Вони хочуть працювати з дому кожну середу і це їх особиста вимога? Дозвольте. Вони хочуть Мак замість ПК? Дайте їм його.

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

Скасувати річні та піврічні звіти
Ваші співробітники не повинні чекати шість-дванадцять місяців, щоб дізнатися, що ви вважаєте, що вони в чомусь досягли успіху і над чим вони повинні попрацювати. Спілкування між менеджерами і співробітниками повинно бути як річка, яка ніколи не перестає текти. Занадто багато компаній все ще застрягли в минулому з їх шкідливими і непродуктивними періодичними звітами. Деякі навіть вимагають часом експертних оцінок. В результаті співробітники таємно об'єднуються, щоб забезпечити один одному хороші відгуки — або співробітники, які не люблять одне одного, будуть валити один одного. У будь-якому випадку результати будуть абсолютно марні і заподіють лише шкоду. Спілкування між менеджером та працівником не повинно відбуватися під час цих штучних обов'язкових періодичних зустрічей віч-на-віч — які зазвичай відбуваються щотижня або два рази в тиждень — і стають незручним вимогою в тих випадках, коли нема чого обговорювати. І керівники, і співробітники повинні відчувати себе відносно комфортно, коли спілкування необхідно. Якщо співробітнику вкрай незручно завести розмову з менеджером або навпаки це показник дуже серйозної проблеми.

Ви не краще ваших співробітників
Розробка програмного забезпечення це робота. Управління розробкою програмного забезпечення це робота. Те, що ваші співробітники звітують перед вами, ще не означає, що ви розумніші або кращі них. Багатьом розробникам програмного забезпечення, насмілюся сказати, що більшості розробників програмного забезпечення подобається бути розробниками. Не плутайте і не дозволяйте вашим працівникам плутати менеджмент з кар'єрним ростом — це просто інша робота, навіть якщо за неї платять трохи більше. Одна з найгірших речей, яку ви могли коли-небудь почути, це як співробітник каже, що його кар'єра застопорилася, тому що його не підвищили до менеджера. Немає нічого поганого в одній професії протягом усього життя, вона тримає ваш мозок в тонусі, а розробка програмного забезпечення залишається видатною кар'єрою. Розробники повинні хотіти потрапити в менеджмент тільки з однієї причини — тому що вони хочуть, а не тому що вважають це кроком вперед.

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

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

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

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

Узагальнення
Ця стаття дуже довгий і заплутаний спосіб допомогти вам дізнатися, як піклуватися про своїх співробітників по розробці програмного забезпечення кращим чином. Якщо ви будете належним чином піклуватися про своїх співробітників, то вони будуть дбати про вас, що призводить до кращих результатів і більш високою задоволеністю кар'єрою для вас і для них. Це в основному компіляція здорового глузду, але я відчував, що він повинен бути зібраний в одному місці для всіх менеджерів програмного забезпечення низького рівня. Хотів би я, щоб ця стаття існувала в мій перший день роботи в якості менеджера. Все це я дізнався на роботі методом проб і помилок і я не можу гарантувати, що це працює для будь-якої команди, але я старався з усіх сил, і з нетерпінням чекаю зворотного зв'язку. Я впевнений, що ця стаття описує все, що повинен зробити менеджер програмного забезпечення на шляху до успіху.

Переклад: Діана Шеремьева
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.