@beem7

Что делать с джуниор программистом, который самоучка и не с этой планеты?

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

Постараюсь разделить его проблемы на две категории.

Категория №1.
Его хобби всегда было не только программирование, но и техника. Делает всякое своими руками, изобретает, конструирует. Именно всякое. Может залезть в совсем незнакомое дело, тщательно подготовиться и сделать качественно. И с первого раза. Иначе (в чем отличие от программирования) будет трата денег на материалы и детали, а он из нищей семьи, поэтому лучше еще немного поэкспериментировать на кошках и потянуть времени, пока придет крутая мысль. Какие проблемы из этого растут?
- неспособность работать с изменяющимся ТЗ. С ним же никогда не было начальника, который мог сделать некорректную UML, лишь бы в срок, а потом бы он ее переделал и заставил разработчика переделать его код по этой UML.
- неспособность делать что-то делать в срок, но не совсем понимая задачу, а потом переделывать. Над ним же никогда не было начальника, который каждый день требовал отчетов, чтобы убедиться, что сотрудник не ничего не делает.
- внимательность и хорошая память. Он не привык делать все так, чтобы легко было проверить отсутствие ошибок. Ведь он способен проверять свое изделие долго. А если подгонять его, то будет куча багов.

Дальше хуже.

Категория №2.
Стрессоустойчивость.
В детстве чувак много хулиганил, врал родителям и т.д. Поэтому крайне закален. Заказчик уже сбился с ног, все время дергает нас, мы все время дергаем его, мы его уже уволили (в очередной раз) и просим лишь доделать долги, а он (вытянув из нас последние силы оправданиями в духе "заказчик идиот, ну не успели мы к дедлайну, так все равно код надо доделать и чтобы он работал! не мешайте мне!") сидит и спокойно копается в коде, устраняет что-то неработающее, параллельно приглаживая всякие мелкие косяки, которые никак нельзя не пригладить, даже если проект сгорел и горим уже мы.
Сам он при этом не понимает, почему мы так же не воюем со своим начальством, с заказчиком, ведь тогда порядка было бы в сто раз больше, а работы меньше. Ведь сколько уже дедлайнов сорванных, а заказчик все еще с нами и все вроде как нормально. Только вот мы-то не спецназ, а просто команда разработчиков. И не можем так торговать своими нервами, у нас сердце пошаливает, голова кружится... Так и умереть можно на рабочем месте.

Категория №3.
Интроверсия.
Он склонен всю задачу целиком держать в своей голове и думать над ней один. И чтобы никто не отвлекал. Обсуждать с кем-либо задачу, даже просто общаться в корпоративном чатике среди рабочего дня - все это вроде не дает видимых проблем, но по нему видно, что это его сильно раздражает.
В целом, нерешаемых задач для него нет. Но вот решаемых задач в срок тоже бывает маловато.
  • Вопрос задан
  • 1695 просмотров
Решения вопроса 2
@anton99zel
29а класс средней школы №7
Во первых:
Нужно разделять личные качества и профессиональные!!
(Какая разница, что он бедный или хулиганил....)
Второе:
Если профессиональные качества вас устраивают, то пусть человек работает и не мешайте ему.
Если не устраивают, то ищите другого специалиста
Третье:
Срыв сроков это не только его вина или еще чья то. Часто так бывает, что это общая вина: заказчик меняет ТЗ, менеджмент обещает сроки, лишь бы ухватить заказ, технический директор не вникает в процесс.... В итоге всё вешается на джуна.
И еще:
Программист это творческая профессия. Это не оператором работать по 8 часов по некому алгоритму. Тут и думать надо и вникать и прорабатывать отдельные моменты. Нужно создавать условия для комфортной работы, а не наседать и стоять над душой. Но чтобы релакс не затягивался, даже долги нужно планировать.
Далее необходимо понять, почему возникают задержки:
Если это плохая планировка времени, то пусть работает как ему удобно (в ночное время или вечернее), если задержки возникают из-за недостатка знаний, значит нужно их подтягивать, включая курсы или помощь наставников.
И:
Он склонен всю задачу целиком держать в своей голове и думать над ней один. И чтобы никто не отвлекал. Обсуждать с кем-либо задачу, даже просто общаться в корпоративном чатике среди рабочего дня - все это вроде не дает видимых проблем, но по нему видно, что это его сильно раздражает.

Меня тоже раздражает отвлекаться каждые 5 минут на сообщения, которые вообще не относятся ко мне. А бесконечные обсуждения могут бесконечно обсуждаться.
Взялись работать - работайте. Летучка 10 минут каждый день с утра. 60 минут в понедельник. И всё. Ибо нех.
С ним же никогда не было начальника

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

Работы было бы меньше, если бы вы, там наверху, между собой всё порешали, а потом уже приходили со своими хотелками, а не переобувались каждый день со своим ТЗ "не знаю что хочу".
Ответ написан
saboteur_kiev
@saboteur_kiev Куратор тега Организация работы
software engineer
Если человек не понимает, что деньги платят не за сделанную задачу, а за сделанную задачу в срок - то штрафовать его за каждый раз, когда он проваливает дедлайн. У него резко понизится мотивация делать какие-то костыли и повысится мотивация успевать в дедлайны.

Если обе стороны это не устраивает - распрощаться. Вы не папа и не мама, перевоспитывать - не ваша задача. Он тоже не малое дитя, должен понимать задачи которые перед ним ставят. Если в задачу входит в срок и он подписался под этим сроком, то должен понимать что игнорировать его нельзя. Понятно что все могут столкнуться с неожиданными проблемами, но это должны быть единичные случаи, а не регулярные.
Или человек не умеет планировать свое рабочее время, или не умеет определять сроки на решение задачи - первое это проблемы разработчика которые он должен решить самостоятельное , второе - это задача тимлида помочь и наладить оценку времени на задачи.

"И не можем так торговать своими нервами, у нас сердце пошаливает, голова кружится... Так и умереть можно на рабочем месте."

Это ОЧЕНЬ СТРАННО, когда дедлайны целого проекта зависят от ДЖУНА. Что-то в вашем проекте вы недоговариваете.
Ответ написан
Пригласить эксперта
Ответы на вопрос 5
BojackHorseman
@BojackHorseman
...в творческом отпуске...
недуг надо в подвиг определять! а вам - учиться оценивать риски. те самые пресловутые "умножить на три".

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

что делать с неграмотным тим лидом и бестолковым проджект манагером? крайнего они уже нашли. джун)))
Ответ написан
@nApoBo3
Если один джун приводит к регулярным срывам дэдлайнов и что-то ещё должен доделать после увольнения иначе опять сроки сорвем, то наверно это ему повезло оказаться за бортом этой лодки, а не тем кто в ней остался.
Оставьте человека в покое, пусть он с собой разбирается сам, у вас сами проблем по горло.
Ответ написан
Zifix
@Zifix
Barbatum
Как уже было сказано, проблема в первую очередь в менеджере, а не в разрабе, хотя и он не подарок.

Что делать? Менять процессы.

Например, в таск трекере при смене статуса карточки на "В работе", разраб обязан проставить ожидаемое время выполнения. Если оно больше 8 часов, значит карточка разбивается на несколько. Любые подзадачи больше 2 часов декомпозируются через чек-лист. Если карточка не сделана в срок, значит это повод обсудить с менеджером, в чем проблема, какие варианты решения, сколько ещё времени надо.

Ещё посмотрите на "Центрирующие парадигмы Фридмана".
Ответ написан
ShockWave2048
@ShockWave2048
imposter
Все указанные симптомы легко лечатся опытом работы в команде.

Если человек не может работать на результат в коллективе, то увольнение адекватный и логичный ход.

Очень странно что за долгий период не был найден человек (команда) которая начала бы результативную поддержку и апдейт проекта.

Контроль кода (code review) и адекватности разраба должен вестись желательно каждый день. Запущенный проект и неадекватный кодер стократно отыграются на ваших нервах и сроках.
Ответ написан
xmoonlight
@xmoonlight
https://sitecoder.blogspot.com
Пусть всё делает по-шагам.
Распишет архитектуру и сдаёт каждый модуль (вначале - логику, затем - рабочий код). Часть модулей - можно поручить делать другим. (устранили 2 проблемы)

Общение: здесь вопрос конструктива. Возможно, вы (команда) хотите отслеживать правильность принятых им решений и выбранных алгоритмов/технологий, а возможно, просто поболтать по проекту и сделать вид, что идёт работа и работают все по своим задачам в тесном общении по проекту.
Нужно смотреть конкретно на детали общения и выявлять причины.
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы