Версия для печати темы Нажмите сюда для просмотра этой темы в оригинальном формате

Форум программистов > УП: Человеческий фактор > Управление молодыми(неопытными программистами)

Автор: SpaceSpace 28.11.2008, 21:24

Хочу спросить совета у уважаемой публики. Такая ситуация: по воле случая пришлось руководить разработкой. В команде 7 разработчиков. Но все молодые, кто чуть лучше кто чуть хуже. В общем уровень можно классифицировать как :"студент". Хоть и имею больше опыта, но к сожалению не приходилось до этого стоять у руля. По новым обязанностям, как то: разработка плана проекта, архитектуры , постановка и распаралеливание задач вроде справляюсь. Но самая большая проблема для меня - подтянуть людей до необходимого уровня. Вся сложность заключается в том, что применяемые технологии неизвестны никому из разработчиков, либо очень мало практического опыта. При постановке задачи люди не могут дать оценку. Мало того, дав её, промахиваются в 3 раза либо вообще не способны справится с задачей. Нередки случаи, когда, дав задачу, приходится самому гуглить и давать линки, ссылки, примеры.  Что я хочу видеть в них: дал задачу-> он её оценил-> разбил сам на подзадачи->объяснил что и как он хочет сделать, я его понял и дал добро, либо не согласился и сказал как нужно сделать. Пока поступаю так: даю задачи не длинее 1 дня и вконце проверяю результат. По опыту знаю что её можно сделать в 3-4 раза быстрее, но соглашаюсь на 1 день, но даже в этом случае результат оставляет желать лучшего - либо потом 2 дня переделывать, либо вообще переписать с нуля. Поскажите, как правильно мотивировать и объяснить человеку, что к задаче надо подходить максимально серьезно- постараться сделать её качественно и быстро, научить давать оценку и держать сроки ... и т.д.

Автор: bars80080 29.11.2008, 00:27

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

Автор: solenko 29.11.2008, 10:35

Цитата(SpaceSpace @  28.11.2008,  20:24 ) В общем уровень можно классифицировать как :"студент". и Цитата(SpaceSpace @  28.11.2008,  20:24 ) Что я хочу видеть в них: дал задачу-> он её оценил-> разбил сам на подзадачи->объяснил что и как он хочет сделать, я его понял и дал добро, либо не согласился и сказал как нужно сделать. Само по себе не совместимо. От джуниора нальзя требовать эстимейт, а, тем более на него полагатся при постоении плана проекта. Обычно невыгодно тратить время ПМ-а на подтягивание ждуниоров и в команду берут еще одного мидла/сеньйора, который и будет этим заниматся.

Автор: SpaceSpace 29.11.2008, 10:35

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

Автор: Samotnik 29.11.2008, 21:00

очень странно, что всех студентов посадили на одни проект К примеру в минске практика такая, что на один проект (где хороших девелоперов около 10 ) ставят 1-2 студента. Они тогда и учаться т.к. обьясняют ребята очень быстро и в состоянии выполнить таски как надо и в срок SpaceSpace, в твоей ситуации скажу, я бы поступил так  собрал бы всех и спросил, что кому мешает, чего им не хавтает. Ведь даже минимальные знания + google  могут дать хороший результат выполнения задач в срок и как надо. Если комуто не хватает знаний, то пусть учаться, хотя как правило всем нехватает не результата, а опыта. А то приходит только со временем и ничего тут не сделаеш насильно, единтсвеный вопрос, кому и сколько времени потребуется .......

Автор: aleksh 29.11.2008, 22:27

можно попробовать сажать их парами, и устраивать коллективную ответственность, хорошо еще сидеть за соседним столом с особо "немотивироваными", а вообще Цитата(Samotnik @  29.11.2008,  21:00 ) собрал бы всех и спросил, что кому мешает, чего им не хавтает. в первую очередь

Автор: Samotnik 29.11.2008, 22:38

SpaceSpace,  имхо главное не давить, не угрожать.  примени психологию

Автор: intr 30.11.2008, 07:00

Жизненно У нас тоже сейчас в компании есть студенты,  и после многочисленных опытов , мы пришли к выводу, что их надо прикреплять к группам реальных программистов (как сказал Samotnik). И тогда от них есть польза и они вроде развиваются Только им обычно достается скучная и неинтересная работа (они так говорят  ), которую не хотят делать опытные программисты. Поэтому им иногда надо давать и сложные и интересные задачи, например по ресерчу p/s Одного не могу понять, наша компания выросла из 5 студентов (со второго-третьего курса) и вроде у нас таких проблем не было. Но тут я не могу себя объективно оценивать

Автор: SpaceSpace 1.12.2008, 07:28

Цитата(Samotnik @  29.11.2008,  21:00 ) где хороших девелоперов около 10 ) ставят 1-2 студента Кризис же. все кто может работать - работают, или по крайней мере стараются найти работу. Сегодня тот кто не билабл - не особо в цене. Цитата(Samotnik @  29.11.2008,  22:38 ) SpaceSpace,  имхо главное не давить, не угрожать.  примени психологию Согласен. осталось дело за малым - применит на практике, что не так однозначно. Цитата(aleksh @  29.11.2008,  22:27 ) можно попробовать сажать их парами, и устраивать коллективную ответственность, хорошо еще сидеть за соседним столом с особо "немотивироваными",  Можно, раньше так и было, пока половина команды не ушло(кризис). Сейчас есть задачи, их надо делать - и делать в срок - поплывут даты и функционал - никто нянчится не будет. В тяжелые времена тяжелый подход - либо джуниор будет давать эстимэйт, либо не будет ждуниора работать тут...

Автор: bilbobagginz 1.12.2008, 23:24

Цитата(SpaceSpace @  1.12.2008,  07:28 ) либо джуниор будет давать эстимэйт, либо не будет ждуниора работать тут...  "студент" - это не уровень знаний а подход с т.з. выкладки на работе. У хорошего студня приоритеты такие:  Цитата первым делом - учёба. а работа - от нее лошади дохнут, и трактора ломаются если у вас просто неопытные молодые работники - им можно (что не обязательно легко) всё объяснить что к чему, и будут как молодцы.  ИМХО, выбери какую-то методологию на основе eXtreme Programming/Аgile Programming. И работайте: в парах, standup/персональные meetings, т.е. чтобы о том как кто-то держит задачи знала вся команда, постоянный контроль. у нас в универе даже студенты умудряются за семестр наклепать неплохие проекты на этой основе. И это при том, что вокруг них бегает 3 инструктора, и разбивают их на 3 группы по 10, в каждой идёт ротация тим-лида - по неделе.  Короче при правильном руководстве - всё вливается в колею. Кстати, я не знаю над какими задачами ты работал, но делать нетривиальные задачи в 3-4 раза медленнее естимейта - не самое страшное, что может быть при работе с наёмниками. Особенно, если идёт работа с отладкой внешнего железа или коммуникаций: только фрилансер будет биться над задачей до посинения.  Наёмник в конце концов отобьёт свои часы + 10-20% внеурочных, и пошлёт тебя куда подальше. Гавное - веди учёт всего процесса и обращай внимание на их прогресс. за хороший этимейт - стимулируй. Так это войдёт в привычку, и потом с этой командой ВСЕ захотят работать. Удачи.

Автор: SpaceSpace 2.12.2008, 09:06

спасибо всем. попробую. если будет что рассказать - отпишусь

Автор: bilbobagginz 2.12.2008, 21:43

конечно будет.  рассказывай и хорошее и грабли, всем очень интересно, да и сам потом посмотришь со стороны, и сможешь чему-то сам у себя научиться ;-)

Автор: SpaceSpace 3.12.2008, 08:43

bilbobagginz,  договорились. p.s. пока явного прироста производительности можно добиться только очень мелкими (0.5 часа) задачами и ежечасовым(получасовым) контролем. Т.е. когда сделана большая работа по декомпозиции, когда видишь решение вплоть до реализации методов - можно скармливать маленькими кусочками - справляются довольно неплохо, но тогда времени вообще не остается ни на что

Автор: Nastya 3.12.2008, 11:16

"настоящий тим-лид -это тот кто пишет такой код, который безопасно могут копи-пастить все остальные" (С) не знаю чей )))

Автор: SpaceSpace 4.12.2008, 10:01

Nastya,  вот я тим лид. но не пишу кода, т.к. за 2 часа выделенного под это время кроме контроля и разговоров с командой больше ничего не успеваю делать. Как программер я деградирую - это факт. Может быть мне рано в тим -лиды? раз я не успел состоятся как программер

Автор: Nastya 4.12.2008, 14:16

SpaceSpace, ну то что я писала  было шуткой  А как известно в каждой шутке есть доля шутки. Насчет не рано ли тебе быть тимом решать 1. тебе 2. твоему начальству. так судить сложно.  Я знаю людей, которые достигнув ОЧЕНЬ высокого уровня не хотят двигаться в сторону руководства проектами и знаю людей которые с малых ногтей туда рвутся.  Но в любом случае успехов тебе. Хотя уже то, что ты не уверен в своих качествах программиста, плохо :(  В общем, лично я ничего посоветовать не могу. увы.

Автор: bilbobagginz 4.12.2008, 17:05

Цитата(SpaceSpace @  4.12.2008,  10:01 ) Может быть мне рано в тим -лиды? раз я не успел состоятся как программер вопрос, на который только время может дать ответ. лидерские/управленческие способности это совсем другое измерение, со способностями кодера не имеющие никакой связи. Удачи.

Автор: Cтpaнник 16.12.2008, 13:41

Цитата(SpaceSpace @ 28.11.2008,  21:24) по воле случая пришлось руководить разработкой. В команде 7 разработчиков. Но все молодые, кто чуть лучше кто чуть хуже. В общем уровень можно классифицировать как :"студент". Хмм.... Видишь ли, мне это представляется большой ошибкой твоего руководства. На самом деле, это серьезный фактор риска, способный "завалить" проект. Тут уж прими как данное и постарайся объяснить это руководству: у тебя не останется времени на то, чтобы лично писать код. Ты успеешь только отслеживать архитектуру, проектировать, планировать задачи (мелко-мелко! и оценивать их длительность придется тебе - у студентов для этого еще нет опыта!) и контролировать выполнение.

Автор: SpaceSpace 17.12.2008, 16:19

Cтpaнник, руководсвто я думаю осознанно пошло  на риск. Видишь ли есть минимум 2 типа проекта, которые можно привести в пример. 1. Стандратная, широкоизвеснтная технология с кучей людей, которые на ней работали. скажем SQLServer+Winforms клиент+WCF+ отчеты на кристале или MSRS. В кого не плюнь - почти каждый собаку съел в этом и может быть лидом. 2. Технология другая, известная или неизвстная - неважно, главное в этом случае: НИКТО c ней не работал, и никакой лид не хочет впрягаться в то в чем у него опыта нет. а теперь сопоставь концы с концами 1. опыта ни у кого нет - вот тебе и жуниоров посадили - их ресурс не так дорог, и если завалятся не так обидно 2. лиды опытные как я уже говорил заняты на реальных проектах, ибо боятся потерять работу, поэтому впрягаться во что-то не дающее 100% результат им не с руки. вот по этому наверное меня и назначили. это и есть управление рисками, только в извращенной форме. работой при провале рискую я и моя команда

Автор: arilou 20.12.2008, 23:26

Цитата(SpaceSpace @  17.12.2008,  16:19 ) никакой лид не хочет впрягаться в то в чем у него опыта нет. Это крайне спорное утверждение.

Автор: SpaceSpace 22.12.2008, 10:08

arilou,  Цитата(arilou @  20.12.2008,  23:26 ) Это крайне спорное утверждение.   это не утверждение, это предположение. В противном случае, ао-моему мнению, назначили бы более опытного для таких задач. Хотя сейчас я вроде начал что-то понимать и эйфория от того что за тебя кто-то работает а ты ничего не делаеш прошла.

Автор: Cтpaнник 24.12.2008, 14:36

Цитата(SpaceSpace @  17.12.2008,  16:19 ) это и есть управление рисками, только в извращенной форме. работой при провале рискую я и моя команда  Совершенно согласен. А теперь взвесь: все профиты от такого "управления рисками" получает твое руководство (а ты - ничего), зато все шишки, синяки и неприятности - ты (а в случае провала это [censored] "руководство" скромно отойдет в сторонку и покажет на тебя пальчиком - "Это он все завалил!"). Неплохое разделение труда, не так ли?  Тебе хочется быть мальчиком для битья?

Автор: arilou 24.12.2008, 18:15

Цитата(Cтpaнник @  24.12.2008,  14:36 ) А теперь взвесь: все профиты от такого "управления рисками" получает твое руководство (а ты - ничего), зато все шишки, синяки и неприятности - ты (а в случае провала это [censored] "руководство" скромно отойдет в сторонку и покажет на тебя пальчиком - "Это он все завалил!"). Неплохое разделение труда, не так ли? smile Тебе хочется быть мальчиком для битья?  Финансовые обазательства несет компания, а не PM.

Автор: mindflyer 13.1.2009, 11:22

Если все новички, то я бы посоветовал следующее: 1. Работать в паре - меньше косяков и быстрее обучение. 2. Ежедневные стендапы. Они вообще полезны, но в такой ситуации вдвойне. Упор делать на проблемах и способах их решения. Аналогично делиться новыми изученными фишками.  3.  Разбить предметную область и технологии на куски и дать каждому для углубленного изучения какой-то кусок. Потом каждый проводит типа семинара, рассказывая, что он узнал, отвечая на вопросы и т.д. Всё вышеперечисленное способствует обмену знаниями и повышает мотивацию/ответственность.

Автор: SpaceSpace 19.1.2009, 16:39

Команду расформировали. "Оптимизация расходов" :(

Автор: arilou 20.1.2009, 02:46

SpaceSpace, кризис

Автор: chief39 3.2.2009, 12:28

Гм... не завидую я тебе. Тут даже трудно от чего-то отталкиваться не видя конкретных студентов. Как я тя понимаю  Над подумать... Добавлено через 2 минуты и 24 секунды Цитата(SpaceSpace @  19.1.2009,  16:39 ) Команду расформировали. "Оптимизация расходов" :(  Хм, не заметил. Не бери к сердцу. Такие команды и в мирное время расформировываются. Это в 90% случаев мертворождённые проекты. А их появление - лакмусова бумажка для эйчаров и вышестоящего руководства, ответственного за планирование. Ты хоть при работе остался?

Автор: SpaceSpace 4.2.2009, 17:13

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

Автор: chief39 4.2.2009, 17:30

SpaceSpace, я не о теме проекта, опыте(горький, кстати - это хорошо). Я о команде студентов, которая вызывает у руководителя только мысль "как бы это всё... этих всех... хоть что-нибудь... ". Я прекрасно понимаю тебя, потому что года три назад пришлось разгребать такую команду.  25 человек, из них трое были не "студенты". Это просто жуть и кроме отличного тренинга "как вести себя в этой ситуации" больше ничего толкового не выйдет. Так что "отличную тему проекта" можно легко сделать мертворождённой. Бросаешь на неё десяток новичков(чем больше, тем лучше), начинающего руководителя и говоришь "нутесссс.... замутите что-нить." И сразу можно отправлять человека за венками

Автор: SpaceSpace 4.2.2009, 17:53

да, так и было только про венки я тогда не думал...

Автор: KP0H 27.2.2009, 17:08

Очень удобный способ подтянуть всех - pair programming. Ставишь пары сильный-слабый программист и они одновременно выполняют одну задачу. Что такое pair programming можно в другом месте почитать, но именно касаемо задачи поддянуть - очень удобно.

Автор: phpsc 5.4.2011, 01:11

Цитата(SpaceSpace @ 28.11.2008,  21:24) Хочу спросить совета у уважаемой публики. Такая ситуация: по воле случая пришлось руководить разработкой. В команде 7 разработчиков. Но все молодые, кто чуть лучше кто чуть хуже. В общем уровень можно классифицировать как :"студент". Хоть и имею больше опыта, но к сожалению не приходилось до этого стоять у руля. По новым обязанностям, как то: разработка плана проекта, архитектуры , постановка и распаралеливание задач вроде справляюсь. Но самая большая проблема для меня - подтянуть людей до необходимого уровня. Вся сложность заключается в том, что применяемые технологии неизвестны никому из разработчиков, либо очень мало практического опыта. При постановке задачи люди не могут дать оценку. Мало того, дав её, промахиваются в 3 раза либо вообще не способны справится с задачей. Нередки случаи, когда, дав задачу, приходится самому гуглить и давать линки, ссылки, примеры.  Что я хочу видеть в них: дал задачу-> он её оценил-> разбил сам на подзадачи->объяснил что и как он хочет сделать, я его понял и дал добро, либо не согласился и сказал как нужно сделать. Пока поступаю так: даю задачи не длинее 1 дня и вконце проверяю результат. По опыту знаю что её можно сделать в 3-4 раза быстрее, но соглашаюсь на 1 день, но даже в этом случае результат оставляет желать лучшего - либо потом 2 дня переделывать, либо вообще переписать с нуля. Поскажите, как правильно мотивировать и объяснить человеку, что к задаче надо подходить максимально серьезно- постараться сделать её качественно и быстро, научить давать оценку и держать сроки ... и т.д. всех уволить. и делать заказы на фрилансерских сайтах.

Powered by Invision Power Board (http://www.invisionboard.com)
© Invision Power Services (http://www.invisionpower.com)