Як зберегти команду добре підготовленою? [зачинено]


11

Зараз я наставляю невелику команду з 4 молодших розробників у невеликій програмі. Вони дуже розумні і часто досягають своїх завдань високоякісною роботою, але я впевнений, що все ще можуть зробити краще - насправді я маю саме такі почуття до себе :) -. До того ж деякі з них більш «молодші», ніж інші.

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

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

Будь-який зворотній зв'язок вітаємо!


3
МІСТЕР. NOLAN ~ Товариство мертвих поетів: "У віці цих хлопців? Не у вашому житті! Традиція, Джон. Дисципліна. Підготуйте їх до коледжу, а решта подбає про себе". Куд не втримається: P +1 за гарне запитання.
Матьє

Відповіді:


9

Ось кілька ідей

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

  • час від часу виконуючи завдання, не пов'язані з роботою, як-от поїхати в Дейв та Бастер, щоб весело провести п’ятницю чи подібні речі .. покращити хімію команди

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


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

1

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


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

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

1

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

Якщо вона не надходить зсередини, це не дасть стійких результатів.

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


1

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

Успіхів у цьому!


1

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

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

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

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


1

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

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

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

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

Іноді безпосередньо мотивація потреби в даній експертизі може допомогти як мотиватор.


1

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

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

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


0

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

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.