Хочу спросить совета у уважаемой публики.
Такая ситуация:
по воле случая пришлось руководить разработкой. В команде 7 разработчиков. Но все молодые, кто чуть лучше кто чуть хуже. В общем уровень можно классифицировать как :"студент".

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

Пока поступаю так: даю задачи не длинее 1 дня и вконце проверяю результат. По опыту знаю что её можно сделать в 3-4 раза быстрее, но соглашаюсь на 1 день, но даже в этом случае результат оставляет желать лучшего - либо потом 2 дня переделывать, либо вообще переписать с нуля.

Поскажите, как правильно мотивировать и объяснить человеку, что к задаче надо подходить максимально серьезно- постараться сделать её качественно и быстро, научить давать оценку и держать сроки ...
и т.д.

тут есть один ньюанс. почему ты стал руководителем? пусть даже небольшого штата?

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

конечно, без личной мотивации человек не сильно уйдёт, надо что-то придумывать. но я не начальник...

и

Само по себе не совместимо. От джуниора нальзя требовать эстимейт, а, тем более на него полагатся при постоении плана проекта.

Обычно невыгодно тратить время ПМ-а на подтягивание ждуниоров и в команду берут еще одного мидла/сеньйора, который и будет этим заниматся.

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

очень странно, что всех студентов посадили на одни проект
К примеру в минске практика такая, что на один проект (где хороших девелоперов около 10 ) ставят 1-2 студента. Они тогда и учаться т.к. обьясняют ребята очень быстро и в состоянии выполнить таски как надо и в срок

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

можно попробовать сажать их парами, и устраивать коллективную ответственность, хорошо еще сидеть за соседним столом с особо "немотивироваными", а вообще

в первую очередь

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

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

Кризис же. все кто может работать - работают, или по крайней мере стараются найти работу. Сегодня тот кто не билабл - не особо в цене.


Согласен. осталось дело за малым - применит на практике, что не так однозначно.


Можно, раньше так и было, пока половина команды не ушло(кризис). Сейчас есть задачи, их надо делать - и делать в срок - поплывут даты и функционал - никто нянчится не будет. В тяжелые времена тяжелый подход - либо джуниор будет давать эстимэйт, либо не будет ждуниора работать тут... 

"студент" - это не уровень знаний а подход с т.з. выкладки на работе.
У хорошего студня приоритеты такие: 

если у вас просто неопытные молодые работники - им можно (что не обязательно легко) всё объяснить что к чему, и будут как молодцы. 
ИМХО, выбери какую-то методологию на основе eXtreme Programming/Аgile Programming.
И работайте:
в парах, standup/персональные meetings, т.е. чтобы о том как кто-то держит задачи знала вся команда, постоянный контроль.

у нас в универе даже студенты умудряются за семестр наклепать неплохие проекты на этой основе.
И это при том, что вокруг них бегает 3 инструктора, и разбивают их на 3 группы по 10, в каждой идёт ротация тим-лида - по неделе. 

Короче при правильном руководстве - всё вливается в колею.

Кстати, я не знаю над какими задачами ты работал, но делать нетривиальные задачи в 3-4 раза медленнее естимейта - не самое страшное, что может быть при работе с наёмниками. Особенно, если идёт работа с отладкой внешнего железа или коммуникаций: только фрилансер будет биться над задачей до посинения. 
Наёмник в конце концов отобьёт свои часы + 10-20% внеурочных, и пошлёт тебя куда подальше.

Гавное - веди учёт всего процесса и обращай внимание на их прогресс. за хороший этимейт - стимулируй.
Так это войдёт в привычку, и потом с этой командой ВСЕ захотят работать.

Удачи.

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

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

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

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

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