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

1. Наша компанія вимагає від розробників вказувати прогрес роботи в трекері помилок, який ми використовуємо, не стільки для моніторингу програмістів, скільки для того, щоб зацікавити зацікавлених сторін про прогрес. Справа в тому, що A лише оновлює прогрес завдання, коли воно виконується (можливо, через 3 тижні після його першої роботи), і це залишає всіх цікавитись, що відбувається в середині тижня розробки. Він не змінив звичку, незважаючи на неодноразові зондування. (Це нормально, розробники ненавидять діловодство, і я теж)
2. Останні 2-3 місяці він у відпустці досить часто через різні події - або він хворий, або мусить відвідувати багато особистих подій тощо. (Це нормально, погані речі трапляються рядно. Це просто збіг)
3. Ми визначаємо спринти або дорожні карти на кожен місяць. І на початку спринту ми обговоримо обсяг роботи, який кожен із розробників повинен виконати у спринті, і розробники отримують, щоб встановити кількість часу, яке їм потрібно для кожного завдання . Зазвичай він не зможе їх виконати. (Це нормально, розробники регулярно пропускають терміни не з їх вини).
4. Я базуюсь у Сінгапурі. Не впевнений, чи це має значення. Так, азіати, як відомо, стримані, але чи це має значення?

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

Це просто почуття, засноване на моєму багаторічному досвіді програміста. Але я можу помилитися.

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

Результат:

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

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

Моє запитання: Як ви можете сказати, чи недостатньо ефективні ваші програмісти? Звичайно, є досвід керівників команди, які знають краще, ніж я? 

Додаткові примітки:

1. Я ненавиджу мікроменеджмент. Отже, все, що ми маємо для нашого програмного процесу, - це Sprint (де завдання ставлять пріоритетні та призначаються, а в кінці місяця - огляд обсягу виконаної роботи). Розробникам потрібно буде оновлювати завдання, як вони йдуть разом.
2. Немає жодної зустрічі зі стопами, або нічого подібного. Головним чином, тому, що ми маємо свободу працювати вдома і всі шанують цю свободу.
3. Хоча я і є тим, хто встановлює термін, але розробники нададуть кошторис для кожного завдання, і я вирішуватиму - на основі кошторису - завдання, які йдуть у конкретний спринт. Якщо вони не зможуть закінчити завдання в кінці спринту, я пересуну їх до наступного. Тож теоретично можна просто виконати лише 1 або 2 завдання протягом усього спринту, а потім перенести решту 99 завдань на наступний спринт, і все одно він буде добре, поки це виправдовує - у вигляді щоденних оновлень прогресу роботи

Це має бути напрочуд простою проблемою.

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

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

Якщо цього немає, у вас виникають ці проблеми.

Регулярні, планові, 1: 1, - чудова ідея. І, як люди вказували, складові не повинні бути ортогональними для роботи з дому. Але вони повинні включати три питання: Що ви робили вчора? Що ви плануєте сьогодні зробити? І той, хто більшість людей забуває ... Що (якщо щось таке) стримує вас?

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

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

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

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

Гарний лов!

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

Знайдіть джерело проблеми

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

Ти не ідеальний

Пам'ятайте, що іноді у вас виникають конфлікти особистості, особливо з інтровертами . Якщо це виявляється конфліктом особистості, подумайте, наскільки далеко ви готові йти, щоб підвищити продуктивність (див. 1)

Все сказане

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

http://deltreey.blogspot.com/2012/07/managing-programmers.html

Я не можу достатньо підкреслити останню частину цього поста.

Якщо ваші розробники взагалі добрі, вони хочуть кодувати.

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

Коли ви відчуваєте, що комусь "дещо складно керувати", як ви описуєте, щоб краще зрозуміти, як працює, і чи існують проблеми (об'єктивні чи суб'єктивні), що впливають на продуктивність членів команди розробників, подумайте про встановлення звичайної практики 1: 1 з вашими Члени команди, як це представлено у чудовій статті «Оновлення», «Відхід» та «Катастрофа» :

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

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

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

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

Ви завжди можете підказати, що він регулярно перевіряє / надає оновлення, щоб мінімізувати подібні конфлікти. Це може дозволити вам подати заявку в плані допомоги команді, а не "я не знаю, що ви робите".

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

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

Безглуздо

Щоденне оновлення статусу є безглуздим. Повідомлення людей "сьогодні я на 2,5% завершений", "сьогодні я 3,74% завершений" - смішно.

Це не надає ніякої цінності зацікавленим сторонам і дратує людей, які виконують цю роботу.

Залиште їх до своєї роботи, безперешкодно.

Безосновні

На яких підставах ви гадаєте, що розробник A "недостатньо ефективний"? Якщо його / її робота проводиться вчасно, це повинно бути досить добре.

Ви кажете, що ненавидите мікроменеджмент, але все, що ви описали, - саме це.

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

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

Небезпечний

Перегляньте основу свого "почуття", що розробник A "недостатньо ефективний". Ви думаєте, що він / вона міг би зробити краще, але на основі яких доказів?

Нещасний! = Низький показник

Продовжуйте так, як описано, і в якийсь момент розробник А, швидше за все, вирішить, що він недооцінений, дав достатньо компанії та знайде іншу компанію. Стискання останніх 0,01% зусиль працівників набагато менш важливо, ніж їх тривалий термін.

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

Щодо оцінки - це класична проблема. Я рекомендую прочитати "Оцінка програмного забезпечення - Демістифікація чорного мистецтва" Стіва МакКоннелла. У цьому випадку ви створюєте враження, що більшість ваших розробників недооцінюють. Це, що цікаво, нормально і рідко звертається. Я б припустив, що ви маєте проблеми з самим процесом оцінки, а не з цією особою.

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

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

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

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

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

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

Одне, що ви можете зробити, це інтегрувати щось на зразок XPlanner із засобом версії.

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

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

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

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

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

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

• ІМО, це дійсно допомагає команді навчитися краще оцінювати оцінки, коли вони можуть бачити, скільки часу потрібно, щоб інколи робити навіть досить просто.

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

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

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

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

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

Недостатній показник?

Інтенсивність падає і пливе під час кар'єри людини. Якщо він коштує більше, ніж він коштує, то поговоріть з ним і спробуйте полегшити його роботу. Або ж почніть шукати заміну.

Зв'язок

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

Майте більш стійкі засоби комунікації

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

Контроль джерела

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

Відокремте засоби від кінців

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

Це мої пропозиції:

1. Інновації: Уява та креативність використовуються для зниження витрат та покращення поточної ситуації.

2. Корпорація: Готовність допомагати іншим досягти поставлених цілей

3. Ініціатива: Спроба позапланових завдань і завдань.

4. Відвідуваність: Відсутність або запізнення, нижче норм.

5. Настороженість: здатність швидко зрозуміти нову інформацію та ситуації

6. Точність та якість: огляди коду, доставка вчасно, швидкість випуску).