Comments 30
Гм. Т.е. вы ищете того, кто с нуля создаст команду, за 5 минут сформирует план проекта, оценит сроки, ресурсы?
А про усреднённый код, это классно. Скажите мне, сколько нужно ресурсов, что бы передать сломавшийся станок из производства в ремонтное подразделение? А зачем нужно передавать? А кто будет участвовать? А сколько это кода усредненого разработчика?
Я никогда не найду специалиста, который мне за 5 минут ответит на такой вопрос. Уж лучше спросите, сколько шариков от тенниса влезает в суперджет) Ну или по пмбоку прогоняйте. Про ценности можно и про то, как они становятся выгодой)
Не "создаст команду", а примерно прикинет, кто в этой команде должен быть. И если вы не можете определить приблизительные сроки проекта в рамках вашей зоны ответственности, то какой от такого руководителя прок? Важно щеки надувать за большие деньги?
Если вы передавали станок из производства в ремонт, то сможете сказать, сколько времени это заняло, не так ли?
Сколько вообще кода пишет один усредненный разработчик в двухнедельный спринт?
И впрямь
Что бы это значило...
Все вот эти вопросы:
Например, у вас есть один аналитик, один фронт разработчик, два бэкендера и тестировщик, какой объем задач они решат за полгода? За какой срок успеют реализовать проект? Сколько вообще кода пишет один усредненный разработчик в двухнедельный спринт? Или, если уровень руководителя выше, за какой срок при известной структуре департамента (её набросали в предыдущем абзаце) будут достигнуты поставленные цели?
... имеют какой-то смысл если это кандидат спрашивает их у интервьюера. Типа, "ну давайте прикинем, расскажите, как у вас обычно это бывает". А если интервьюер такое спрашивает у кандидата, то самый правильный ответ будет "двадцать шесть". "Что двадцать шесть"? "А что – "сколько кода" "?
Теперь я знаю, как обеспечивается воспроизводство поголовья суетологов…
У нас в компании разработка идет по Scrum, без сроков, планы на год, конечно, есть, но они постоянно срываются. И ничего, все работают, никого не уволили. Ну сделали на месяц позже или на три - ну и что ? На то есть определенные причины.
Браво. "Ну сделали на 1-3 позже ну и что". Прям сквозит и отношение к своему продукту и к работе и к заказчику. Спасибо что подкрепляете мою уверенность в том как работает современный IT и во что он превратился.
Заказчик внутренний. Компания очень крупная, зависимостей от смежных команд много (так как много интеграций с другими сервисами), но у этих смежных команд есть свои планы по разработке, которые точно также зависят от других смежных команд (потому что тоже много интеграций :-D). Именно поэтому обычно разработка затягивается. В условиях ограниченных ресурсов нет возможности взять и сделать, а иногда, как известно, появляются срочные задачи, которые надо делать, бросив остальные. Сейчас вы скажете, что страдает планирование - возможно, и так. Тем не менее, продукты создаются и релизятся.
без сроков, планы на год, конечно, есть
То есть сроки есть, но сроков нет. Интересно.
Я сделаю точно в срок только
1 доп хотелки и хорошие идеи все на потом на другой бюджет
2 на старте будут детальные ТЗ и спецификации - никаких аджайлов
3 все неопределенности в ТЗ либо реализуем по простому либо далеко потом
4 время на реализацию и тестирование будет заложено с двойным или тройным запасом в зависимости от активности ключевых заказчиков на этапе т.з.
Я думаю ключевые пользователи и спонсоры проекта при таком раскладе легко подвинут сроки
Мне показалось, что в статье есть довольно общая информация, прям general. Для начала, руководителя какого уровня мы в первую очередь должны оценивать: лида отдела на проекте, лида отдела в компании, руководителя проекта и т.д.? Для каждого нужен разный подход, чтобы оценить его навыки. Как минимум степень погружения и степень необходимости делегирования.
Как лид отдела на проекте и фичеоунер я могу сказать, что мне довольно много приходится (сравнительно много) работать руками. При этом необходимо не только менеджить свой отдел, но и менеджить мини-команды в рамках разработки. И исходя из своего опыта и насмотренности я могу сказать, что для руководителей всех звеньев самыми критичными навыками являются умение делегировать, аналитическое мышление и умение признавать свои ошибки вовремя, а таковые будут, это точно. Это лишь мое субъективное мнение.
Я ни в коем случае не хочу сказать, что статья плохая. Мне было приятно с ней ознакомиться, очень хороший слог и интересные мысли. Спасибо за материал.
Я пока регистрировался на Хабре, перестал злиться на эту статью
Не понял статью. Ради статьи написано)
На собесе лидов спрашиваю что было сделано из достижений, как шел процесс, какие коммуникации и с кем были, сильные/слабые моменты, где приходилось вмешиваться и как решались проблемы с другими подразделениями. С каким багажом приходит к нам человек.
И да, я не беру лидов, без опыта работы руками. Человек должен системно расти от исполнителя до руководителя. Поэтому спрашиваю и про ручную работу.
"Сколько кода пишет программист" это абстрактно, сам раньше писал, мог за ночь накидать много рабочего кода, мог за неделю немного гавнокода накидать.
На собесе лидов спрашиваю что было сделано из достижений, как шел процесс, какие коммуникации и с кем были, сильные/слабые моменты, где приходилось вмешиваться и как решались проблемы с другими подразделениями
То есть вы просто разговариваете о вечном, а не о конкретных задачах лидов?
я не беру лидов, без опыта работы руками
Очень часто встречал такое, что в вакансии указано "тимлид", а нужен просто хороший программист, чтобы работу работать. Может у вас так?
"Сколько кода пишет программист" это абстрактно
Нет, это вполне конкретно. Вот у нас есть задача - выкопать траншею, и есть два землекопа. Сколько времени займет выполнение задачи? Можно ли это оценить? А почему с программистами иначе работает?
А вам сколько кода нужно написать?
А траншея в чистом поле или в городе, где возможно нахождение коммуникаций, старых фундаментов, строительного мусора в конце концов? ) Если в чистом поле, то грунт песчанистый или через полметра пойдёт глина? А время года и погодные условия надо учитывать? Что-то много вопросов возникает для одной траншеи. Что-то тут не то...
Потому что писать код не грядки копать. Одно дело исполнять работу по одному и тому же алгоритму с поправкой на локальные случаи, а другое дело когда вся работа представляет из себя работу с локальными случаями, для решения которых нужно всякий раз думать по иному. Глупый вопрос
Как собеседовать того, кто ничего (руками) не делает
По длине ногтей!
Автор умеет писать поджигающие сообщество посты, я даже зарегалась в хабре, настолько хочется оставить комментарий.
"кандидат просто согласится на все обязательства, так как очень хочет попасть на позицию" - может конечно это мое восприятие искажено, но когда я, как руководитель, хожу на собесы, это я выбираю в какой компании мне работать и какие обязанности выполнять.
Бррр, просто жуть от всех последующих высказываний, я не дочитала до конца. Запишу себе имя автора и его компанию, чтобы обходить ее за километр.
По опыту, и в том числе негативному
Сначала о негативе
Была проблема с лидом, который нет был ориентирован на результат, а больше на соблюдение процессов. Это проявляется в том, что у нас срыв сроков, а лид вместо поиска вариантов решения и причин рассказывает, почему это норм. В этом случае было и по технологии норм, и код норм - но в сроки мы никак не вписывались. Сделали аудит кода с привлечением других лидов, получилось что разработчики делали работу реально медленно. Т.е. сложность и объем задачи никак "не бились" с тем, сколько на нее тратилось времени. Причем были разговоры, и на примерах конкретных тасок, и вопросы по объему unit-тестов, и по другим процедурным моментам - но на тет-а-тет встречах лид "да-да-да", а потом уже с командой - "нет-нет-нет". Ну и бесконечные торги по поводу стори поинтов и т.д. уже достали половину команды.
Также был кейс, когда лид был очень опытный и знающий, но вместо реальной работы изображал деятельность команды и прикрывал косяки. Когда баги стали открываться многократно, начали разбираться и вскрылось, что половина команды просто подгоняла код под конкретные ошибки найденные сегодня, и по фиг, что решение в целом не работает. Было ли причиной непонимание бизнес задач, либо просто "усталость" от жизни - неясно, так как после разгона половины команды с лидом, оставшая часть дописала решение, причем код был по большей части переписан, ну уже под надзором и постоянным ревью, иногда в стиле "сидим вдвоем, вот дока, вот код, сличаем и принимаем решение по пациенту".
Т.е. получается, что проблемы были не из-за того, что лиды чего-то не знали технически. С этим ни разу не было проблем, так как если не знаешь - всегда можно изучить. Проблемы были с сфот скилами, причем если первый кейс еще можно было идентифицировать, то второй - когда идет сознательный саботаж, практически нет.
Вывод такой: крайне внимательно мониторить по началу, и если что не так - тут же давать задачу "разобраться". Если раз "не то", два "не то" - смысла дальше идти с таким вожаком стаи нет.
На собесе можно отсеять тех, кто либо технологически не шарит, либо еще не набрался, как и чего говорить. Конечно бывает, что сразу ловишь понимание, что с таким человеком в одной лодке не очень хочется, но лично у меня опыта как так провести собес чтобы это почувствовать нет.
Возможно на следующий проект попробую как-то в эту сторону копнуть
Этап 1. Проверка на вменяемость.
1.1. Проверка у нарколога.
1.2. Проверка у психиатра.
1.3. Проверка у сексопатолога.
1.4. Проверка у психолога.
Сдача всех необходимых анализов строго обязательна. Крайне желательно, чтобы решение вынес консилиум независимых врачей. Если есть проблемы или сомнения, то лучше такого типа не брать.
Интересный подход к найму. Не проще ли рассказать, как процесс ограгизован у вас и спросить про способы оптимизации? Если, вы описываете методику и вопросы, то следовало бы дать ориентиры на правильную реакцию претендента и ответы, которые вы ожидаете получить от кандидата. Лично мне, нравится задавать вопрос про проблемы с которыми сталкивался кандидат. В ответе я ожидаю услышать про реальные сложности и способы которыми их решали. Следом я задаю вопрос, про причины этих проблем и хочу получить хотя бы намёк, на команду и руководителя. И в завершение, какие выводы сделали и какие меры приняли для исключения подобных ситуаций в будущем. В моем понимании, руководитель умеет не только диаграммой Ганта пользоваться, но и имеет адекватную реакцию на непредвиденные ситации.
Во многом согласен, но сама формулировка "ничего не делает руками" сильно напрягает.
Контроль - одна из важнейших функций руководителя! Например, если в интеграционных проектах он не способен верифицировать спеку и диаграмму последовательности UML от аналитика/архитектора (нижний и средний уровень руководства) или понять отчёт QA (читать ПМИ, отчёты, это если руководитель уровнем повыше), то грошь цена такому руководителю. А это сразу говорит о неких необходимых компетенциях в части (уметь делать руками), хотя бы на верхнем или абстрактном уровне. И это легко проверить.
За одно всплывут факты по практическим кейсам, хороший руководитель не упустит возможности похвастаться своим опытом.
Как собеседовать того, кто ничего (руками) не делает — руководителя