Як мені керувати командою з різним рівнем кваліфікації?

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

Як я повинен підтримувати стандарти, уникаючи мікроуправління? Чи достатньо зробити кілька діаграм, запланувати кілька оглядів коду та довіряти, що я зможу виправити все, що вони можуть зламати, або я повинен пройти маршрут TDD і написати явні тести для задоволення команди?

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

Бічна примітка: під час щорічного огляду не повинно бути сюрпризів.

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

Я також рекомендую максимально використовувати автоматизацію:

• Запропонуйте команді використовувати такий інструмент, як NDepend або Resharper, якщо ви перебуваєте у царині .Net. Налаштуйте стандартні правила, якщо вони вам не подобаються.
• Автоматизуйте тестування максимально практично.

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

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

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

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

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

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

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

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

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

Обговорюйте, погоджуйтеся, записуйте, моделюйте та повідомляйте стандарти (наприклад, умовне іменування, кодування найкращих практик та структур папок).

Робіть постійні та регулярні тестування та перевірки якості. Повідомте про це якнайшвидше, коли ви побачите невідповідності.

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

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

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

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

Я менеджер і можу бути технічним керівником (за останні кілька років я зіграв останню роль для підвищення лідерства в команді. У будь-якому випадку, деякі думки:

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

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

Як найдосвідченіший розробник у команді, я б очікував від вашого важкого тренування .

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

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

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

Існує кілька різних списків, які я б сподобався переглянути з вашої позиції:

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

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

У чомусь це все зводиться до спілкування. Удачі!

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

Певний інструктаж щодо того, як вести розмову, може бути для всіх. У мене був професор коледжу, який зробив це для мене, і це було дуже корисно.