Комментарии 168
Спасибо за статью. И сразу вопрос про:
Это удобно тем, что временные затраты на найм снижаются лишь до поиска подходящих резюме и лёгкого интервью с соискателями для проверки на адекватность и рассказа про тестовое задание, и, конечно, непосредственно проверки задания.
На хабре уже же обсуждалось, что подобный подход отсеивает людей, которые:
- Семейные и не хотят думать о коде дома. Они пропустят вашу компанию.
- Имеют статьи, полезные проекты на github. Они просто потратят вечер на свой проект и уйдут к другим.
- Серьезно работающих. У них сначала не будет времени, а потом они не захотят вам писать, так как будет впечатление что "легкое тестовое задание человек делал уж неделю, наверное туп как пробка". Вы можете так не думать, однако специалист будет считать, что менеджеры среднего звена именно так и будут думать о нем.
=====
Другой вопрос: а вы сами стали бы решать задачу? Несложную, на middle уровень, например, lock-free алгоритм очереди с возможностью итерирования и т.д.?
=====
друг фронт, который в то же самое время начал подумывать уйти с фриланса, поэтому мы смогли быстро заткнули вакансию, а я получил премию за приведение сотрудника
Считаете ли вы это коррупцией или кумовством, что наняли в свою команду друга? Был ли при найме конфликт интересов? Он тоже решал задачу, или так взяли?
=====
Какую часть своего времени вы программирует? И как вы все-таки считаете, вы уже менеджер среднего звена, или же еще team lead?
=====
Ещё очень вредны моменты, когда люди отказываются брать на себя ответственность.
А какая премиальная часть за взятие ответственности? Если ноль, то рациональнее не брать ответственность. А если берут — то нет ли проблемы с работой, если, как мы видим, люди явно поступают иррационально с проектом?
=====
Как вы решаете проблему с недоверием сотрудникам к вам?
Какой большой комментарий. Спасибо за него
Про тестовое задание
Собеседование и тестовые обсуждались уже множество раз в том, числе и на Хабре. И у всех подходов есть свои минусы. Самым оптимальным, честным, точным, наверное, можно считать приглашение на целый день в офис, где соискатель будет работать, так как будто бы он уже часть команды. Но даже он имеет проблемы с теми пунктами, которые вы описали. Например, серьёзно работающий человек не сможет найти целый день на работу на другую фирму.
Я считаю, что в конкретно нашем случае тестовое задание очень важно, так как Битрикс требует очень много специфических знаний.
Плюс Битрикс в 80% случаев подразумевает разработку интернет-магазинов и довольно скучные задачи, поэтому считаю нечестным перед кандидатом проверять его общие знания и логику, а потом давать какие-то однотипные задачи. Поэтому тестовое задание по сути является разработкой формы заказа и у соискателя есть лишний шанс подумать хочет ли он заниматься этим 40 часов в неделю, так как не всем такое по душе.
Сам я бы решал тестовые задачи, что собственно и делал некое количество раз
Про друга
Тут выгода для меня/нас была в том, что, во-первых, я мог очень быстро связаться с соискателем и доступно объяснить, а, во-вторых, я успел с ним сделать несколько проектов и уже знал его уровень.
Но чтобы избежать кумоства и чего-либо подобного, я не принимал никакого участия в его собеседовании и принятии решения о приёме на работу. Но это частный случай нашей компании. Наш директор имеет довольно уверенные технические знания, поэтому он мог принять решение самостоятельно.
Про самоощущение
На сегодняшний момент где-то половину своего времени я пишу код, как рядовой программист, считаю это важным для себя и компании. Остальное время по большей части тоже «техническое»: код-ревью, консультации ребят, оценки задач, выбор подходов. Поэтому считаю себя лидом, а не менеджером.
Про ответственность
На самом деле всё начинается с таких вещей как «Этот код писал не я, я его не буду править», «Я решил не подключать библиотеку А, так как думаю, что это не в моей компетенции», «У меня на тесте не повторилась ошибка, на бою не буду трогать админку»,…
Довольно эфемерный момент для «начисления очков», поэтому премирования нет.
Сам я борюсь с этими стопами через разрушение мифов и страхов у ребят.
Про недоверие
На самом деле не сталкивался с этой проблемой.
Но во второй части расскажу поддержание авторитета. Довольно интересный момент
Про тестовое задание
Собеседование и тестовые обсуждались уже множество раз в том, числе и на Хабре. И у всех подходов есть свои минусы. Самым оптимальным, честным, точным, наверное, можно считать приглашение на целый день в офис, где соискатель будет работать, так как будто бы он уже часть команды. Но даже он имеет проблемы с теми пунктами, которые вы описали. Например, серьёзно работающий человек не сможет найти целый день на работу на другую фирму.
Я считаю, что в конкретно нашем случае тестовое задание очень важно, так как Битрикс требует очень много специфических знаний.
Плюс Битрикс в 80% случаев подразумевает разработку интернет-магазинов и довольно скучные задачи, поэтому считаю нечестным перед кандидатом проверять его общие знания и логику, а потом давать какие-то однотипные задачи. Поэтому тестовое задание по сути является разработкой формы заказа и у соискателя есть лишний шанс подумать хочет ли он заниматься этим 40 часов в неделю, так как не всем такое по душе.
Сам я бы решал тестовые задачи, что собственно и делал некое количество раз
Про друга
Тут выгода для меня/нас была в том, что, во-первых, я мог очень быстро связаться с соискателем и доступно объяснить, а, во-вторых, я успел с ним сделать несколько проектов и уже знал его уровень.
Но чтобы избежать кумоства и чего-либо подобного, я не принимал никакого участия в его собеседовании и принятии решения о приёме на работу. Но это частный случай нашей компании. Наш директор имеет довольно уверенные технические знания, поэтому он мог принять решение самостоятельно.
Про самоощущение
На сегодняшний момент где-то половину своего времени я пишу код, как рядовой программист, считаю это важным для себя и компании. Остальное время по большей части тоже «техническое»: код-ревью, консультации ребят, оценки задач, выбор подходов. Поэтому считаю себя лидом, а не менеджером.
Про ответственность
На самом деле всё начинается с таких вещей как «Этот код писал не я, я его не буду править», «Я решил не подключать библиотеку А, так как думаю, что это не в моей компетенции», «У меня на тесте не повторилась ошибка, на бою не буду трогать админку»,…
Довольно эфемерный момент для «начисления очков», поэтому премирования нет.
Сам я борюсь с этими стопами через разрушение мифов и страхов у ребят.
Про недоверие
На самом деле не сталкивался с этой проблемой.
Но во второй части расскажу поддержание авторитета. Довольно интересный момент
Проблема с тестовым заданием обычно всего одна — оно должно быть оплачиваемым по полноценному рейту. Тогда соискатель с удовольствием его выполняет (особенно с собственной оценкой времени))).
Это одновременно и сдерживает работодателя от раздутых заданий, и позволяет соискателю спокойно показать свой уровень без нервотрепки и стресса ("я на них три дня потратил, а они мне отказали").
Кстати, хорошая идея.
Нужно будет обсудить внутри фирмы.
Так по идее можно и переманивать людей
Нужно будет обсудить внутри фирмы.
Так по идее можно и переманивать людей
Поддерживаю!
На одном из собеседований на удалёнку, когда мне предложили сделать тестовое задаение, я прямо сказал: бесплатно делать не буду. После чего мы обсудили критерии приёмки, стоимость и сроки. Результатом стало долгое плодотворное сотрудничество.
Собственно я бы хотел соискателеям дать совет: уважайте себя и цените своё время, адекватный работодатель это оценит, а не адекватный… а он вам нужен?
На одном из собеседований на удалёнку, когда мне предложили сделать тестовое задаение, я прямо сказал: бесплатно делать не буду. После чего мы обсудили критерии приёмки, стоимость и сроки. Результатом стало долгое плодотворное сотрудничество.
Собственно я бы хотел соискателеям дать совет: уважайте себя и цените своё время, адекватный работодатель это оценит, а не адекватный… а он вам нужен?
Полностью согласен с комментарием.
Также добавлю, что пройдя 100+ собеседований в разных компаниях (как успешно, так и не успешно, с согласие на работу, так и с отказом на работу после приглашения), а также при проведении собеседований хотя бы несколько десятков раз, вырабатывается навык, когда в течении 15 мин или меньше точно можешь сказать, что тебе сотрудник/компания не подходит, а еще за 30-45 мин понять-допускать к испытательному сроку/идти на испытательный срок или нет.
За 30-45 мин как раз идет диалог-что делали, как решали проблемы и т д и т п, т е даже без тестов-просто в режиме свободного диалога.
Все остальное, особенно задачи на более, чем 2 часа должны быть уже на испытательном сроке, где стороны обоюдно присматриваются друг к другу, а не одна из сторон (часто этот маленький, но важный момент забывают и сами работодатели).
Если работать надо в команде, то обязательно на собеседовании кроме руководителя должен быть 1-2 сотрудника из команды, с которыми чаще всего нужно будет взаимодействовать, чтобы коллеги определили (да и сам кандидат) для себя на сколько подходит человек в плане коммуникаций, знаний и нет ли интуитивного отторжения или еще чего.
Вот и все
А минусы есть по обеим сторонам, важно понять на какие компромиссы и уступки можно пойти и что можно улучшить опять же с обеих сторон, т к предела в совершенстве нет.
Также добавлю, что пройдя 100+ собеседований в разных компаниях (как успешно, так и не успешно, с согласие на работу, так и с отказом на работу после приглашения), а также при проведении собеседований хотя бы несколько десятков раз, вырабатывается навык, когда в течении 15 мин или меньше точно можешь сказать, что тебе сотрудник/компания не подходит, а еще за 30-45 мин понять-допускать к испытательному сроку/идти на испытательный срок или нет.
За 30-45 мин как раз идет диалог-что делали, как решали проблемы и т д и т п, т е даже без тестов-просто в режиме свободного диалога.
Все остальное, особенно задачи на более, чем 2 часа должны быть уже на испытательном сроке, где стороны обоюдно присматриваются друг к другу, а не одна из сторон (часто этот маленький, но важный момент забывают и сами работодатели).
Если работать надо в команде, то обязательно на собеседовании кроме руководителя должен быть 1-2 сотрудника из команды, с которыми чаще всего нужно будет взаимодействовать, чтобы коллеги определили (да и сам кандидат) для себя на сколько подходит человек в плане коммуникаций, знаний и нет ли интуитивного отторжения или еще чего.
Вот и все
А минусы есть по обеим сторонам, важно понять на какие компромиссы и уступки можно пойти и что можно улучшить опять же с обеих сторон, т к предела в совершенстве нет.
Вы проходили собеседования больше 100 раз?
За 6+ лет своей ппофессиональной деятельности да, т к это мое хобби и в среднем хожу на собеседование 2-3 раза в
месяц
Где вы столько контор находите куда собеседоваться, и не смотрят на вас странно когда раз в 3 месяца в одно и тоже место идете, так же не боитесь что вам дадут согласие, а вы откажетесь, а вам через 3 месяца нужно менять работу, а там уже обиженные за ваш отказ сидят.
Я в одно и тоже место редко хожу
Компаний много от мало до велико и необязательно IT, где нужна разработка теже кредитные органтзации, логистика, торговля и т д и т п
Компаний тьма
Все в основном через spb.hh.ru, реже через знакомых и еще реже через Хабр и Гитхаб
Какие обиды?
Это рынок и обе стороны рискуют
И если брать в целом, то можно вывести жизненный цикл жизни специалиста в рамках одной компании или одного проекта, которая заключается в определенном стеке технологий, предметной области, подходах к разработке, поддержке и оптимизации.
Данный цикл длится по разному, но обычно составляет 1, 3 или 5 лет, реже 10 лет, т к более 5-ти лет находится в одном проекте или более 10-ти лет вариться в одной предметной области чревато для компетенций относительно рынка.
И не стоит забывать, что профессия-это еще и хобби и страсть к познанию, а работодатель-это спутник и инструмент, позволяющий знания применить в практике. Итого: Вы выбираете себе удобный и нужный инструмент, исходя из Ваших пожеланий и потребностей профессионального роста, равно как и работодатель выбирает себе более подходящего по его мнению сотрудника.
С компанией, которая чего-то боится мне не по пути, равно как и сотруднику, который боиться вырваться из зоны комфорта сложно осознать, что все на самом деле очень просто и нет ничего сложного.
На счет количества вакансий-напр, .NET или MS SQL в spb.hh.ru наберите поиск и каждую неделю там новые вакансии и их в среднем сотни за месяц от нескольких десятков компаний, а за год-более сотни таких компаний. И потому 100 компаний за 6+ лет это еще немного (по крайней мере исходя из статистики). Но все охватить-такой цели не стоит. Однако, если хочешь держать руку на пульсе, что происходит на рынке, как не нужно проводить собеседование, анализировать и понимать что от тебя хотят и что скрывается в несказанности рекрутером, то считаю просто необходимостью походить по собеседованиям (особенно тем, кто проводит эти собеседования и сидит на месте более 10-ти лет). Лишним не будет точно, а за частую и полезно в развитии как коммуникабельных способностей, так и телепатических)
Да и к тому же, частотбывает, что ты хочешь в компанию, но тебе отказывают либо сразу, либо на последнем этапе собеседований. И сколько таких ситуаций было-я же не обижаюсь.
Грамотный работодатель не заканчивает процедуру поиска, пока не начнется по факту первый рабочий день нового сотрудника, и у работодателя всегда есть в заначке еще кандидаты в случае непрохождения новым сотрудником испытательного срока (инициатива может быть как от работодателя, так и от сотрудника-не стоит и этот момент забывать).
Агалогично и у специалиста должны быть запасные варианты (правда здесь немного похуже, т к единицы из компаний понимают эту необходимость, а большинство просто обижаются или боятся раз их оставили в заначку)
На счет увольнений-здесь не такой большой опыт (всего несколько раз, а не десятки), однако конечно если решили сами уволиться, то работу нужно довести до логической точки и заранее в фоне подготовить почту для быстрой передачи знаний, а также сообщить работодателю о своем решении как можно раньше, а не за 2 недели, чтобы и у того было время откорректировать рабочий процесс с учетом Вашего ухода.
Также можно оставить отзыв о работодателе и договориться о рекомендациях Вам.
Мне тоже нравится ходить по собеседований ради самих собеседований. Посмотреть как люди живут, что предлагают, какие проблемы хотят решить, где офисы снимают.
Правда уже несколько лет не ходил никуда
Правда уже несколько лет не ходил никуда
Позволю себе ответить с моей точки зрения.
Что и показывает, что компания должна реально оценивать свой уровень. В Амазоне — да, в местной конторе — нет. Если место интересное и хочу эту работу — я делал.
По статистике, мы сообщали кандидатам о тестовом задании после первого разговора. На больше сотни кандидатов, было пару недовольных (одного при этом наняли) но всего пару несделанных заданий и ни одного явного отказа делать.
Бонус всегда приятен, да и определенные усилия со своей стороны есть :)
А серьезно, если речь не про госконтору, то главное результат. Если человек полезен команде, то и я, и команда, и руководство заинтересовано, чтобы нанять наиболее комфортного мне как тимлиду человека. Потому если я на 100% уверен — посоветую так что друга возьмут. Но это палка о двух концах — если не сработает, то доверие ко мне будет серьезно подорвано, потому я тут осторожен.
Бонус в данном случае вторичен, но опять таки если начальство устраивает — то почему бы и нет?
Премии не всегда должны быть деньгами. Правильная похвала тоже работает. Сотрудники хотят понимать, что лид их ценит и доверяет. Опять таки это повышает шансы на развитие или хотя бы на неувольнение при сокращении бюджета.
Ну и далее дополнительные вещи — команда и менеджмент в целом гораздо терпимее к ошибкам того, кто берет ответственность и делает результат. А ошибки бывают у всех. Ну и вообще быть на хорошем счету у руководства выгодно.
а вы сами стали бы решать задачу?
Что и показывает, что компания должна реально оценивать свой уровень. В Амазоне — да, в местной конторе — нет. Если место интересное и хочу эту работу — я делал.
По статистике, мы сообщали кандидатам о тестовом задании после первого разговора. На больше сотни кандидатов, было пару недовольных (одного при этом наняли) но всего пару несделанных заданий и ни одного явного отказа делать.
Считаете ли вы это коррупцией или кумовством, что наняли в свою команду друга?
Бонус всегда приятен, да и определенные усилия со своей стороны есть :)
А серьезно, если речь не про госконтору, то главное результат. Если человек полезен команде, то и я, и команда, и руководство заинтересовано, чтобы нанять наиболее комфортного мне как тимлиду человека. Потому если я на 100% уверен — посоветую так что друга возьмут. Но это палка о двух концах — если не сработает, то доверие ко мне будет серьезно подорвано, потому я тут осторожен.
Бонус в данном случае вторичен, но опять таки если начальство устраивает — то почему бы и нет?
А какая премиальная часть за взятие ответственности? Если ноль, то рациональнее не брать ответственность.
Премии не всегда должны быть деньгами. Правильная похвала тоже работает. Сотрудники хотят понимать, что лид их ценит и доверяет. Опять таки это повышает шансы на развитие или хотя бы на неувольнение при сокращении бюджета.
Ну и далее дополнительные вещи — команда и менеджмент в целом гораздо терпимее к ошибкам того, кто берет ответственность и делает результат. А ошибки бывают у всех. Ну и вообще быть на хорошем счету у руководства выгодно.
На хабре уже же обсуждалось, что подобный подход отсеивает людей, которые
В контексте все правильно:
Итого в разработке сложилась следующая ситуация:
один “старичок”
я
трое абсолютных новичков
работа ещё не налажена
часть знаний уже потеряна
Ибо что это за новички, что нос воротят от тестового задания — в топку их.
Блин, тоже пишу статью, но скорее про собеседования, коллег и управление, чем про себя.
Я скорее архитектор/тех.дир, нежели разработчик.
В свое время понял, что больше всего меня не устраивало в компании именно руководство и как бы я не любил разработку, как бы не вертелся на пике bleeding-edge и не ценил объективно низкий уровень реальной конкуренции, определенно было ощущение, что занимаюсь чем-то не тем.
Добили собеседования после смены компании, некомпетентность начальства, ведущих разработчиков(именно как руководителей) уже на этом этапе бросается в глаза.
В итоге пришел на проект с ужасающей архитектурой, безопасностью и тратами на разработку, но зато все по методологиям, менеджер мог расписать каждые 10 минут. Стал ведущим разработчиком, затем тех.диром, а потом ушел, но определился со своей ролью на будущее.
Сейчас, для маня главное — прозрачность, стресс порождается ее отсутствием. Например, если предложенные тесты на вакансии проверяют только на стрессоустойчивость(например простые задания, или задания на запоминание википедии), от них выгодней открыто отказаться ( написать, что задач не будет). Любые правила и защита — автоматизируемы, если правило нельзя автоматизировать и нет ответственного лица — оно не служит для защиты, а следовательно — устраняется.
Я искренне ценю мысли, подобные вашим впечатлениям из части "Чему я научился..." и так же искренне желаю вам не предавать эти убеждения и расти, как в разработке, так и руководстве.
Спасибо за тёплые слова. Уверенный, что вы хороши в своей деятельности и у вас всё получится!
Я провёл свои первые полгода с уклоном в руководство и каждый месяц очень многому учусь. Больше всего надеюсь, что команда под моим началом будет развиваться, особенно в индивидуальном плане каждый из коллег
Я провёл свои первые полгода с уклоном в руководство и каждый месяц очень многому учусь. Больше всего надеюсь, что команда под моим началом будет развиваться, особенно в индивидуальном плане каждый из коллег
Используете ли Github, Gitlab, Bitbucket или что-то подобное? Использование pull-реквестов устранило бы проблемы с мержами в команде и облегчило код-ревью.
Да, мы работаем через Bitbucket.
В последнее время я тоже думал о переходе разработчиков на пулл-реквесты, может быть проведу эксперимент хотя бы на одном проекте.
Но мы сейчас активно расширяемся, плюс сами ребята быстро растут в профессиональном плане, а также на проектах большое количество подрядчиков (сеошники, 1сники, контент-менеджеры, ..), так что возможно закреплю по человеку на проект и тоже пулл-реквесты.
В последнее время я тоже думал о переходе разработчиков на пулл-реквесты, может быть проведу эксперимент хотя бы на одном проекте.
Но мы сейчас активно расширяемся, плюс сами ребята быстро растут в профессиональном плане, а также на проектах большое количество подрядчиков (сеошники, 1сники, контент-менеджеры, ..), так что возможно закреплю по человеку на проект и тоже пулл-реквесты.
Можно выделить немного времени в конце дня и совместно делать код-ревью всех pull-реквестов созданных в течении дня, разбирая проблемы по горячим следам со всей командой. Это позволит сократить совместные сессии, но при этом улучшить качество кода. Плюс неплохо бы прикрутить не только автотесты, но и статические анализаторы(типа sonarqube, phpstan и т.д.) к pull-реквестам, это позволит выловить потенциальные баги еще на этапе ревью.
Хм, крутая идея. Нужно будет подумать над
Жирный +1, сам собирался написать.
Pull-реквесты очень сильно повысили качество у нас.
Что используем: TFS + git, основные ветки имеют полиси — мерж только через пулл-реквест, с билдом и привязанными тасками. Билд, понятное дело, с тестами и линтером. Более медленный статический анализ и UI-тесты проходят ночью. Есть формальный чеклист для ревьювера — проверить закрытие задачи, репортинг времени, тесты, документацию — то что пока не смогли автоматизировать. Отключать полиси имеет право только техлид и никогда (почти) этого не делает (это к вопросу о доверии — техлид работает в тех же условиях).
Перед релизом QA команда смотрит список фактически попавших в билд задач (вот это очень хорошо сыграло, перестали пропускать недоделки и забытые вещи). И проверяет что ночной билд зеленый. Даже если не зеленый, всегда понятно можно ли релизить.
ИМХО есть огромная разница между «иногда я делаю код-ревью» и «каждая строчка кода обязательно проходит ревью». За один день ревью перестает восприниматься как придирка и становится частью процесса.
Pull-реквесты очень сильно повысили качество у нас.
Что используем: TFS + git, основные ветки имеют полиси — мерж только через пулл-реквест, с билдом и привязанными тасками. Билд, понятное дело, с тестами и линтером. Более медленный статический анализ и UI-тесты проходят ночью. Есть формальный чеклист для ревьювера — проверить закрытие задачи, репортинг времени, тесты, документацию — то что пока не смогли автоматизировать. Отключать полиси имеет право только техлид и никогда (почти) этого не делает (это к вопросу о доверии — техлид работает в тех же условиях).
Перед релизом QA команда смотрит список фактически попавших в билд задач (вот это очень хорошо сыграло, перестали пропускать недоделки и забытые вещи). И проверяет что ночной билд зеленый. Даже если не зеленый, всегда понятно можно ли релизить.
ИМХО есть огромная разница между «иногда я делаю код-ревью» и «каждая строчка кода обязательно проходит ревью». За один день ревью перестает восприниматься как придирка и становится частью процесса.
два одинаковых работника, но один из них читает профессиональную литературу и/или ведёт личные проекты, а второй нет.
Вы действительно считаете что после того как человек проработал 8 часов за день, потратил еще 2 часа на дорогу приедет домой и у него будет здоровое желание повести личный проект?
Не считаю и не от кого не требую. Упомянул личные проекты, т. к. заметил корреляцию между наличием личных проектов и прогрессом в профессиональном плане.
И, кстати, с этими мыслями мы ввели добровольно-принудительное обучение в рабочие, оплачиваемые часы.
Но к оправданию людей с проектами, у нас таких как минимум двое (Мы не поднимаем этот вопрос из-за этических соображений). У одного проекты на Андроиде, у другого на Ларавеле. Так что это как хобби получается.
И, кстати, с этими мыслями мы ввели добровольно-принудительное обучение в рабочие, оплачиваемые часы.
Но к оправданию людей с проектами, у нас таких как минимум двое (Мы не поднимаем этот вопрос из-за этических соображений). У одного проекты на Андроиде, у другого на Ларавеле. Так что это как хобби получается.
>> заметил корреляцию между наличием личных проектов и прогрессом в профессиональном плане.
В общем-то, логично… Наличие личных проектов может говорить о том, что у человека нет личных/домашних проблем, которые жрут время и нервы, а также о том, что состояние выгорания ему в данный момент не угрожает. Плюс, сторонние проекты в смежных областях могут быть неплохим источником свежих идей.
В общем-то, логично… Наличие личных проектов может говорить о том, что у человека нет личных/домашних проблем, которые жрут время и нервы, а также о том, что состояние выгорания ему в данный момент не угрожает. Плюс, сторонние проекты в смежных областях могут быть неплохим источником свежих идей.
Кстати, да. Эти же ребята ещё и самые спокойные и стрессоустойчивые
Я, вообще, думал, что причина в свежих идеях, потому что один парень вырос за несколько месяцев с миддла до сеньора по моему имхо и один из немногих, кто использует ООП вне взаимодействия с D7
Расскажите, как вы разделяете мидла и сеньера? Мой коллега пришел пару месяцев назад на позицию джуна, и с первых дней пользует в модулях и компонентах новомодные битриксовые тренды, д7 и орм. Но ведь сеньором его из за этого назвать нельзя? Или можно?
Это очень, очень субъективно. Я использую наверное 20 или 30 пунктов часть из которых вообще из soft skills.
Кстати, опыт показал, что миддл может использовать D7 очень хорошо. Проблема как раз в том, что чтобы писать на Битриксе на 5+ не нужно быть очень крутым программистом из-за компонентного подхода и любви Битрикса к «портянкам» кода. Да и D7 плохо продокументирован и не все решения в нём мне нравятся.
В вашем случае, если человек будет хорошо писать код, отвлечённый от D7, с нуля, например, что-нибудь связанной с апи от/для стороннего сервиса, то он уже не джун.
Но опять же, у меня занимает сколько-то недель код-ревью и общения, чтобы понять уровень разработчика
Кстати, опыт показал, что миддл может использовать D7 очень хорошо. Проблема как раз в том, что чтобы писать на Битриксе на 5+ не нужно быть очень крутым программистом из-за компонентного подхода и любви Битрикса к «портянкам» кода. Да и D7 плохо продокументирован и не все решения в нём мне нравятся.
В вашем случае, если человек будет хорошо писать код, отвлечённый от D7, с нуля, например, что-нибудь связанной с апи от/для стороннего сервиса, то он уже не джун.
Но опять же, у меня занимает сколько-то недель код-ревью и общения, чтобы понять уровень разработчика
Я нахожу два-три раза в неделю время на свои проекты или на изучение чего-то нового. Ибо то, что нравится, не требует больших волевых усилий. А вот подработки по вечерам прекратил, потому что начал ненавидеть и их, и основную работу.
Подработки я совсем не одобряю.
Они реально забирают ментальные силы и желание работать. Особенно, если у тебя есть жена/дети/девушка/друзья/..., которые вечером ждут твоего внимания.
Единственный способ борьбы с ними повышение ЗП до некоего уровня, когда человеку будет хватать на всё.
Я рад, что вам нравится ваша сфера и вы готовы делать чуть больше в ней, чем требуется работой
Они реально забирают ментальные силы и желание работать. Особенно, если у тебя есть жена/дети/девушка/друзья/..., которые вечером ждут твоего внимания.
Единственный способ борьбы с ними повышение ЗП до некоего уровня, когда человеку будет хватать на всё.
Я рад, что вам нравится ваша сфера и вы готовы делать чуть больше в ней, чем требуется работой
НЛО прилетело и опубликовало эту надпись здесь
Статья отличная, пишите еще!
Также подкину идейку: статья про мерджи бд в гите для битрикса отлично бы зашла.
Также подкину идейку: статья про мерджи бд в гите для битрикса отлично бы зашла.
Ответственный за проект бэк [...] разбирался в кодовой базе vue, где большую часть писали не они двое (я как раз, кстати). [...] попал в ужасную ситуацию — работал до часу ночи всю неделю, сильно стрессовал, но и на него же по итогу свесились все шишки, в особенности из-за того, что он всё это время повторял “починю к обеду / к концу дня / к ночи / к утру”. [...] всё это вылилось в то, что пока мы решали его дальнейшую судьбу, он сам написал заявление об увольнении, так как устал такого стресса.Хочется надеяться, что фраза «решали дальнейшую судьбу» означает «решали, сколькократную премию ему дать за усердную и сверхурочную работу», а не «решали, не уволить ли чувака, который из кожи вон лез спасти всех от бага, который внёс не он».
НЛО прилетело и опубликовало эту надпись здесь
К сожалению, про премию не было и речи.
Парень действительно был отличным: ответственный, позитивный, трудолюбивый, но тут личные качества не спасали, так как образование таких «чёрных дыр» у него было слишком частой практикой.
Звучали разные идеи. Самыми приятными и безобидными были идеи вроде «сидеть с ним вдвоём и вместе оценивать задачи, которые он собирается делать, потому как проблема возможно отчасти в оценке»
Парень действительно был отличным: ответственный, позитивный, трудолюбивый, но тут личные качества не спасали, так как образование таких «чёрных дыр» у него было слишком частой практикой.
Звучали разные идеи. Самыми приятными и безобидными были идеи вроде «сидеть с ним вдвоём и вместе оценивать задачи, которые он собирается делать, потому как проблема возможно отчасти в оценке»
Видел уже такую ситуацию, к сожалению это типично оканчивается увольнением, причём именно что и «сам работник с радостью ушёл». Интересно, что сам один раз так попал, и тогда как раз менеджмент спас ситуацию без увольнения меня :)
Выработал для себя пару правил, которые надеюсь могут помочь. Во-первых надо вовремя распознать, что человек закопался. Предложить пересмотреть сроки, подвинуть дедлайн. Во-вторых просто пропускать мимо ушей «починю через час» — это всё равно не правда, ясно ведь. Далее если не помогло — срочно передать всю задачу целиком другому. Это сложно, ведь этот может оказаться самым знающим, тогда хотя-бы подключить второе мнение. Лид или менеджер должен взять на себя всю ответственность за провал и перенести сроки. Больно и не хочется, но надо. И только после успешного релиза обсудить «что пошло не так и как сделать лучше в следующий раз». Но сначала признать, что человек таки сделал хорошую работу, в общем то.
А далее уже параллельно думать, нужен ли он в команде. Понимать, что с точки зрения морали команды, повесить всех собать и дать уволится — плохое решение.
Опять же, доводилось работать с людьми, у которых были проблемы с оценкой, с коммуникацией оценки, вообще с тем чтобы сказать «нет». В некоторых случаях (не всегда, конечно), лучше всего просто учитывать и подстраиваться самому.
Выработал для себя пару правил, которые надеюсь могут помочь. Во-первых надо вовремя распознать, что человек закопался. Предложить пересмотреть сроки, подвинуть дедлайн. Во-вторых просто пропускать мимо ушей «починю через час» — это всё равно не правда, ясно ведь. Далее если не помогло — срочно передать всю задачу целиком другому. Это сложно, ведь этот может оказаться самым знающим, тогда хотя-бы подключить второе мнение. Лид или менеджер должен взять на себя всю ответственность за провал и перенести сроки. Больно и не хочется, но надо. И только после успешного релиза обсудить «что пошло не так и как сделать лучше в следующий раз». Но сначала признать, что человек таки сделал хорошую работу, в общем то.
А далее уже параллельно думать, нужен ли он в команде. Понимать, что с точки зрения морали команды, повесить всех собать и дать уволится — плохое решение.
Опять же, доводилось работать с людьми, у которых были проблемы с оценкой, с коммуникацией оценки, вообще с тем чтобы сказать «нет». В некоторых случаях (не всегда, конечно), лучше всего просто учитывать и подстраиваться самому.
Придя с галеры, в дикие прерии, он одолел дракона, показав как стучать на барабане.
На момент начала моей работы менеджер ставила задачи ужасно. Пример: название задачи — “Исправить баг на сайте” и всё: ни какого-либо описания, ни скринов, только название и отсылка к проекту. Были конечно попытки донести принципы SMART и важность описания задач до менеджера, но все начинания разбивались об “У меня нет времени расписывать задачи”.У нас похожая история.
Я тестировщик. Недавно я написал нашим тимлидам, что давайте введем критерии качества для тикетов и задач. Их элементарным качеством должна быть проверяемость. Т.е. если это баг- разработчик должен иметь возможность воспроизвести сценарий самым простым способом. (Я это называю «дай шанс разработчику пофиксить проблему») Если это задача, то она должна быть расписана так, чтобы третье лицо могло убедиться в том что она выполнена. Так же и разработчик, после обработки задачи, должен занести в тикет всю информацию необходимую для тестировщика или любого третьего лица, чтобы убедиться в том, что задача была действительно выполнена или проблема была исправлена.
Все отговорки — банальное проявление или попытка проявления халатности. А халатность в работе заводит в конце концов в Петлю Страха
Это не так трудно как кажется. Я когда пишу тикет, даю полный расклад, потому что хочу чтобы задачу быстро решили. А потом, проверяя исполнение, я не хочу мучительно вспоминать как воспроизводится эта проблема. А цикл от создания тикета до его решения бывает и пару месяцев, и тогда ты уже точно можешь не надятся на свою память. И это окупается. Редкие случаи когда разрабам приходится подходить и что-то переспрашивать. И даже в таких случаях все сводится к тому, что я открываю тикет в багтрекере и просто зачитываю из него с параллельной демонстрацией на продукте. Ну поленились прочитать. Бывает.
Когда я завожу технический баг, например на наш тестовый фреймворк, то прилагаю файл с тестом с помощью которого можно проявить проблему. Так же, если я хочу какую-то фичу в тестовом фреймворке, то к текстовому описанию с указанием моего намерения (зачем, для какого сценария мне это надо) прилагаю файл с тестом, в котором показано, как я хочу это использовать. Задача исполняющего — сделать так чтобы это заработало. Такие таски выполняются на удивление быстро и с минимумом доработок.
Короче: чем хуже описание — тем дольше будет обрабатываться. Причем не в масштабе «час-два» а в масштабе «день-неделя». Это связано с устройством работы мозга. Все что непонятно он с удовольствием откладывает на потом.
Описания задач крайне важны, вы правы.
Я рад, что у нас уровень постановки сильно повысился. Но странно, что не все считают это критически важным даже с несколькими годами опыта.
Я рад, что у нас уровень постановки сильно повысился. Но странно, что не все считают это критически важным даже с несколькими годами опыта.
А это уже Ваша работа. Вон там человек написал:
И это неправильно. Девелопер не имеет права отложить баг на потом. Зато может с поддержки техлида просто вернуть назад тестировщику с пометкой «непонятно». В клинических случаях когда название задачи «исправить баг на сайте» — ответ должен быть аналогично идиотским, вроде "исправил баг на сайте", либо "открыл сайт, он открылся. Значит бага нет.".
А потом ведь менеджер может и спросить, как это у нас в проекте 10 критических багов и все тестерам вернули.
Все что непонятно он с удовольствием откладывает на потом.
И это неправильно. Девелопер не имеет права отложить баг на потом. Зато может с поддержки техлида просто вернуть назад тестировщику с пометкой «непонятно». В клинических случаях когда название задачи «исправить баг на сайте» — ответ должен быть аналогично идиотским, вроде "исправил баг на сайте", либо "открыл сайт, он открылся. Значит бага нет.".
А потом ведь менеджер может и спросить, как это у нас в проекте 10 критических багов и все тестерам вернули.
ответ должен быть аналогично идиотским, вроде "исправил баг на сайте", либо "открыл сайт, он открылся. Значит бага нет.".
Я думаю, для дела будет лучше написать, "не удалось воспроизвести, недостаточно информации" и привести ссылку на принятые рекомендации по оформлению ошибок типа https://geteasyqa.com/qa/write-bug-report/, но адаптированную для вашего продукта.
Наверное это правильная стратегия, но не все в силу характера будут перечить. Кто-то будет старательно вчитываться, пытаться понять, не понимать, и уже уставшим переключаться на что-то более понятное.
Плюс чёткое описание задачи и разбиение на подзадачи помогает более адекватно оценивать время на её решение. При общем описании много нюансов можно просто не увидеть.
Плюс чёткое описание задачи и разбиение на подзадачи помогает более адекватно оценивать время на её решение. При общем описании много нюансов можно просто не увидеть.
UPD. Не сориентировался в цепочке ответов думал, что отвечали мне.
Мое мнение — это неправильная, конфликтная стратегия.
Перечить не надо. Надо уточнять. Идиотский ответ — это уже «перечить» (вы сами понимаете, что проблема есть, но тот, кто зарегистрировал ошибку не знает как о ней сообщить и не понимает, что данных недостаточно. Кстати, тут возникает вопрос, почему он не понимает. Может быть софт не подсказывает как это делать правильно? У него нет инструкции?)
Четкое описание задачи — это навык. Обычно он появляется от опыта. Надо помогать коллегам его приобретать. Обычно люди, которые могут решать проблемы в целом, стоят дороже чем люди которые копают отсюда и до обеда.
Дорогой программист (при прочих равных) должен иметь приветливый дуракоустойчивый интерфейс с проверкой на ошибки. Или будте готовы к распределению стоимости в пользу более дорогого консультанта, тилида или кого-то еще кто будет вас понимать.
Мое мнение — это неправильная, конфликтная стратегия.
Перечить не надо. Надо уточнять. Идиотский ответ — это уже «перечить» (вы сами понимаете, что проблема есть, но тот, кто зарегистрировал ошибку не знает как о ней сообщить и не понимает, что данных недостаточно. Кстати, тут возникает вопрос, почему он не понимает. Может быть софт не подсказывает как это делать правильно? У него нет инструкции?)
Четкое описание задачи — это навык. Обычно он появляется от опыта. Надо помогать коллегам его приобретать. Обычно люди, которые могут решать проблемы в целом, стоят дороже чем люди которые копают отсюда и до обеда.
Дорогой программист (при прочих равных) должен иметь приветливый дуракоустойчивый интерфейс с проверкой на ошибки. Или будте готовы к распределению стоимости в пользу более дорогого консультанта, тилида или кого-то еще кто будет вас понимать.
вы сами понимаете, что проблема есть, но тот, кто зарегистрировал ошибку не знает как о ней сообщить и не понимает, что данных недостаточно.
«Не понимает» — это возможно, конечно надо уточнить, помочь, подсказать. Однако формулировка «исправить баг на сайте» — это скорее лень и неуважение к времени окружающих. Если один раз — ок, если повторяется — то человека нао заставить работать доступными методами.
В своем петпроекте в разделе форума "ошибки" я ввёл и описал подобные правила заведения багрепортов. Обычные юзеры, многие далёкие от разработки или тестирования стали ВСЕГДА писать нормальные описания ошибок. Я не представляю как люди за зарплату могут этого не делать. Похоже на саботаж, мне кажется.
НЛО прилетело и опубликовало эту надпись здесь
Я довольно предвзято отношусь к надписям на английском, хотя встречаю их только в коммитах, не в задачах. Даже те, кто знают язык, сильно сокращают тексты.
Шаблоны это хорошо. Они наталкивают на идеи и экономят ментальные силы
Шаблоны это хорошо. Они наталкивают на идеи и экономят ментальные силы
Шаблон по сути не решает. От просто придает структуру.
Вот описание случайно выбранного бага на файрфокс
Все аттрибуты присутствуют — легче анализировать от этого не становится. У человека на его машине по убунтой че-то там подвисает в файрфоксе при загрузке страницы. Такие заявки скорее всего заведомый глухарь.
Я практически никогда не завожу на подобное тикеты. Если эта проблема не воспроизводится на как минимум еще одной машине — этой проблемы не существует.
В заявке нет никакой попытки дифференциального диагноза. Вам разработчик что — Гендальф Белый? Извилины встрепенул, и сразу все ясно? Да у него нет шансов!
Пусть лучше потратит время на решение, того, что можно решить.
Это, по моим понятиям, безответственно давать разработчикам такие тикеты. Разбазаривание ценнейшего ресурса.
Или если уж решил заводить на это тикет, то сделай дифф анализ, возьми еще одну машину, переустанови операционку, поставь другую операционку, возьми другую версию операционки. Столько всего можно попробовать прежде чем создать репорт. Дай человеку пищу для анализа. Прояви участие, ведь тебе это нужно.
Вот описание случайно выбранного бага на файрфокс
Описание
User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:60.0) Gecko/20100101 Firefox/60.0
Build ID: 20180607193927
Steps to reproduce:
* Open a new tab
* Paste an address in.
* Press enter.
Actual results:
* Spinner appears in tab.
* No content ever loads in page (blank page).
* Spinner never stops or times out.
* Right-clicking window no menu appears.
This happens about 10% of the time.
Happens on 3 different networks (two separate WiFi networks at separate locations and via tethered phone network).
Loading the same URL via Curl instantly returns (see attached gif).
Disabled all add-ons, still happens.
Disabled «Use hardware acceleration when available», still happens.
Expected results:
* Page should load.
Version 60.0.2 (64-bit)
Ubuntu 14.04.5 LTS
Build ID: 20180607193927
Steps to reproduce:
* Open a new tab
* Paste an address in.
* Press enter.
Actual results:
* Spinner appears in tab.
* No content ever loads in page (blank page).
* Spinner never stops or times out.
* Right-clicking window no menu appears.
This happens about 10% of the time.
Happens on 3 different networks (two separate WiFi networks at separate locations and via tethered phone network).
Loading the same URL via Curl instantly returns (see attached gif).
Disabled all add-ons, still happens.
Disabled «Use hardware acceleration when available», still happens.
Expected results:
* Page should load.
Version 60.0.2 (64-bit)
Ubuntu 14.04.5 LTS
Все аттрибуты присутствуют — легче анализировать от этого не становится. У человека на его машине по убунтой че-то там подвисает в файрфоксе при загрузке страницы. Такие заявки скорее всего заведомый глухарь.
Я практически никогда не завожу на подобное тикеты. Если эта проблема не воспроизводится на как минимум еще одной машине — этой проблемы не существует.
В заявке нет никакой попытки дифференциального диагноза. Вам разработчик что — Гендальф Белый? Извилины встрепенул, и сразу все ясно? Да у него нет шансов!
Пусть лучше потратит время на решение, того, что можно решить.
Это, по моим понятиям, безответственно давать разработчикам такие тикеты. Разбазаривание ценнейшего ресурса.
Или если уж решил заводить на это тикет, то сделай дифф анализ, возьми еще одну машину, переустанови операционку, поставь другую операционку, возьми другую версию операционки. Столько всего можно попробовать прежде чем создать репорт. Дай человеку пищу для анализа. Прояви участие, ведь тебе это нужно.
НЛО прилетело и опубликовало эту надпись здесь
результат от использования шаблонов — строго положителен.это однозначно так. Причем я заметил, что хорошие практики ведения тикетов иногда приживаются и перенимаются другими тестировщиками. Например я первой строчкой пишу на какой конкретно сборке был сделан тест (одна версия у нас содержит множество сборок, под разные платформы, языки и пр. ) Это сразу отсекает множество вопросов при воспроизведении, и говорит, «я проводил тест только на этом билде и ни на каком другом.»
У нас используют в шаблоне A(ction), O(bservation), E(xpectation) выглядит это примерно
так
можно еще добавить P(recondition) A1:…
A2:…
O2:…
A3:…
O3:…
E3:…
A2:…
O2:…
A3:…
O3:…
E3:…
Кто-то пишет блок А потом блок O, и нужно сверять номера, но удобнее когда они чередуются «сделал-увидел-сделал-увидел-ожидал»
И такой нумерованый пошаговый подход тоже помогает, когда хочется написать роман или наоборот ничего не приходит в голову, он подталкивает «тупо» описать то, что наблюдаешь после этого действия, не вкладывая в это наблюдение никакой оценки. А потом, что ты ожидал получить, честно как есть. Может ожидание и не верно, но «в отделении» разберутся.
Здесь скорее проблема в сложновоспроизоводимости самого бага. В 90% случаев такие описания очень помогают, так как по сути содержат в себе мини-инструкцию: сразу понятно куда копать.
Плюс даже если баг воспроизводится только на одном компьютере- не факт что такие условия сложатся только у него. Вот из моего опыта за последние пару недель:
— У одного клиента не проходили запрос на сайт, так как в url содержалось слово advertise, и такие запросы резал Adblock. Без Adblock не воспроизводилось.
— У другого был заблокирован один и CDN, с которого сайт подтягивал скрипты
— у третьего в один момент роутер стал резать http-запросы, которые были длиннее X байт (такие клиенты по сайту ползали нормально, однако отправка больших форм не проходила).
А у меня сайт, я вообще к инфраструктуре клиента не имею никакого отношения.
Это же не значит, что такие задачи надо откладывать.
Плюс даже если баг воспроизводится только на одном компьютере- не факт что такие условия сложатся только у него. Вот из моего опыта за последние пару недель:
— У одного клиента не проходили запрос на сайт, так как в url содержалось слово advertise, и такие запросы резал Adblock. Без Adblock не воспроизводилось.
— У другого был заблокирован один и CDN, с которого сайт подтягивал скрипты
— у третьего в один момент роутер стал резать http-запросы, которые были длиннее X байт (такие клиенты по сайту ползали нормально, однако отправка больших форм не проходила).
А у меня сайт, я вообще к инфраструктуре клиента не имею никакого отношения.
Это же не значит, что такие задачи надо откладывать.
Как вы вообще находили проблемы в таких нетривиальных случаях?
Особенно третий
Первые два ещё можно через удалённый доступ быстро распознать
Особенно третий
Первые два ещё можно через удалённый доступ быстро распознать
Тут ответ скучный: подключился по удалёнке, и стал отправлять форму, которая не отправлялась, по частям, думая что может быть в форме есть какое-то содержание, которое режется на стороне клиента. После сокращения форма действительно стала отправляться. Ну а потом методом тыка убедился, что это происходит не из-за содержания, а именно из-за размера отправляемых данных: банально «ааааа» отправляется, а «ааааааааа» — не отправляется (букв а конечно было больше).
С другой стороны, логично написать что воспроизводится редко и потому приоритет низкий.
На последней неделе был случай, когда нашёл странное место в коде, и смутно вспомнил что видел баг. Перепроверил, исправил, все довольны. Если бы бага не было — мог бы подумать что так и надо.
Срабатывает редко, но бывает. А вообще должен быть критерий, какие баги надо сразу править, а какие можно отложить пока не всплывут.
На последней неделе был случай, когда нашёл странное место в коде, и смутно вспомнил что видел баг. Перепроверил, исправил, все довольны. Если бы бага не было — мог бы подумать что так и надо.
Срабатывает редко, но бывает. А вообще должен быть критерий, какие баги надо сразу править, а какие можно отложить пока не всплывут.
Да, мне тоже было непонятно это. Тем более, что у человека, который хуже всех ставил задачи, что-то около 20 лет опыта в IT. Хотя возможно это и есть причина
"У меня нет времени расписывать задачи"
А чем он[a] занимался?
Мы сразу говорим, что самое главное для нас это лишь уложиться в сроки решения задачи (называет сам исполнитель) и в конце показать рабочий код в репозитории.
Тут вы немного нарушаете роль оценки и планирования в Agile. И раз уж Вы решили внедрить Scrum — одну из Agile методологий, то разобраться с ее ролью придется. Видеоролик на эту тему от одного из 17 подписантов Agile манифеста https://youtu.be/eisuQefYw_o
Одной из самых больших проблем в компании было постоянное превышение сроков по задачам.
Если будет интересно, буквально вчера я изложил наш опыт как мы в разы увеличили темпы разработки.
Я, знаете ли, не до конца уверен, что его эффективность была всего лишь результатом применения «четырех принципов». Дело в том, что в истории нет абзаца «и вот мы внедрили эти четыре принципа в команде, и все стали работать так же быстро как он».
Со стороны (для меня) это больше похоже на карго-культ. Вы приписываете особенности наблюдаемым факторам. Упуская из виду те, которые не наблюдаете.
Вот как это звучит:
Когда человек работает сам по себе он всегда эффективнее человека работающего в команде. Ему не надо координировать свои действия, отчитываться, ходить на собрания, планирования — он сидит и фигачит. Пришла задача, сел делать, сделал, взялся за следующую. В принципе даже со стула можно не вставать.
Вот я, например, пишу тесты на четыре команды в общем 30+ разработчиков, и весьма эффективно. Просто потому, что я работаю сам по себе. Я эксперт в своей области. Проблемы в тестах или приложении я определяю как правило навскидку. Могу править тестовые скрипты вслепую (не запуская их на приложении для проверки), потому, что точно знаю как работает их код. Но за рамками моего «княжества» мои «супер способности» пропадают.
Если меня заставить делать еще и какую-то менеджерскую работу, обучать кого-то, делегировать, координировать, вся моя эффективность сразу сойдет на нет. И общая эффективность сойдет на нет. Потому что четыре новичка, которыми управляет сениор, никогда не провернут столько же, сколько сделает сениор сам, без чужой помощи.
И архитектура тестового кода у меня рассчитана на то, чтобы быстро писать новые тесты. Можно было бы там классовые структуры наворотить — пробовал — понял, что это меня только тормозит. Для себя вывел принцип: «Не корми кодом архитектуру, корми кодом приложение». В моем случае тесты. Вот и весь аджайл.
Со стороны (для меня) это больше похоже на карго-культ. Вы приписываете особенности наблюдаемым факторам. Упуская из виду те, которые не наблюдаете.
Вот как это звучит:
«У нас был менеджер- лучше я на свете не встречал, так вот, он каждый день чистил зубы три раза, даже на работе, и отжимался по утрам.» А теперь о пользе зарядки и ежедневной гигиены...Это может быть большим заблуждением. Ведь причина может быть и не (только) в этом.
Когда человек работает сам по себе он всегда эффективнее человека работающего в команде. Ему не надо координировать свои действия, отчитываться, ходить на собрания, планирования — он сидит и фигачит. Пришла задача, сел делать, сделал, взялся за следующую. В принципе даже со стула можно не вставать.
Вот я, например, пишу тесты на четыре команды в общем 30+ разработчиков, и весьма эффективно. Просто потому, что я работаю сам по себе. Я эксперт в своей области. Проблемы в тестах или приложении я определяю как правило навскидку. Могу править тестовые скрипты вслепую (не запуская их на приложении для проверки), потому, что точно знаю как работает их код. Но за рамками моего «княжества» мои «супер способности» пропадают.
Если меня заставить делать еще и какую-то менеджерскую работу, обучать кого-то, делегировать, координировать, вся моя эффективность сразу сойдет на нет. И общая эффективность сойдет на нет. Потому что четыре новичка, которыми управляет сениор, никогда не провернут столько же, сколько сделает сениор сам, без чужой помощи.
И архитектура тестового кода у меня рассчитана на то, чтобы быстро писать новые тесты. Можно было бы там классовые структуры наворотить — пробовал — понял, что это меня только тормозит. Для себя вывел принцип: «Не корми кодом архитектуру, корми кодом приложение». В моем случае тесты. Вот и весь аджайл.
Это, кстати, одна из причин, почему я написал статью. До этого не управлял людьми и считаю, что делаю это пока не эффективно
Это ловушка. Если работать таким составом, то сеньор будет погребён под грудом мелких задач, а новички так и не будут развиваться
И общая эффективность сойдет на нет. Потому что четыре новичка, которыми управляет сениор, никогда не провернут столько же, сколько сделает сениор сам, без чужой помощи.
Это ловушка. Если работать таким составом, то сеньор будет погребён под грудом мелких задач, а новички так и не будут развиваться
Я, знаете ли, не до конца уверен, что его эффективность была всего лишь результатом применения «четырех принципов». Дело в том, что в истории нет абзаца «и вот мы внедрили эти четыре принципа в команде, и все стали работать так же быстро как он».
Хорошее замечание, спасибо, добавил пару строк.
На самом деле, темпы разработки выросли не только у тех, кто работал с ним, но и, по цепной реакции, у тех, кто работал уже с этими, и даже в других компаниях, и так на протяжении уже нескольких лет.
Будет очень интересно и полезно почитать. Спасибо
Прочитал вашу статью, понравилось. Зацепился за другие — также интересно. Но вот чекать ваш блог на новые статьи неудобно. Вы где то еще их публикуете? Или может подскажете инструменты чтобы следить за источниками типа вашего блога?
Вы, Vasek18, видмо, весьма гордитесь своим новым назначением, и вас просто таки распирает от необходимости похвастаться поделиться вашим успехом «карабканья по корпоративной лестнице» со всем миром? Правда, похоже, что определенные особенности корпоративной «этики», равно, как и человеческой психологии, вам пока не удалось постигнуть… Искренне надеюсь, что вам не придется писать через месяц-другой статью, «Как я потерял работу после публикации статьи на Хабре»…
все начинания разбивались об “У меня нет времени расписывать задачи”
Автоматический reject на "задачи" подобного типа обычно решают ситуацию.
Т.е. конечно, сначала вежливая просьба, потом получение ЧСВ "я слишком занят/а чтобы...", а уже только потом reject, жалоба "обиженного" индивидуума, чьи "очень важные задачи проигнорированы", общение с начальством "обиженного", аргументация проблемы, после чего "обиженный" получает люлей ещё и от начальства и наконец-то исправляется.
Во-вторых, мы решили не устраивать экзамен на собеседовании, а давать очень объёмную задачу, приближенную к нашим повседневным… Задачу на самом деле может решить и джун за пару вечеров,...
ИМХО — плохая практика. Лично для себя принцип отказываться от вакансий, в которых предлагают задачи требующие более 3-4 часов, просто потому что уже несколько раз тратил на подобное несколько вечеров, а результат нулевой.
P.S. Кстати, наличие тестировщиков — тоже ощутимо влияет на результат. Не "тестирующих разработчиков", а профессиональных, системных тестировщиков. Чтобы минимизировать фейлы на 2-3 разрабов должен быть 1 "тестер".
Мы, кстати, взяли одного ручного не так давно. Вроде бы отлично справляется и помогает в общем плане
Vasek18 можете вкратце рассказать как ваш тестировщик и разработчики работают вместе? Вы даете ему задачи на верификацию фичей? Он участвует в планировании спринта?
1) Да, мы начали хладнокровно ставить задачи на стоп, если их нельзя взять в работу, даже если они очень важные и срочные. Более менее помогло
2) К сожалению, собеседования это лотерея. Но мы не можем позволить себе брать миддлов и сеньоров без тестового.
2) К сожалению, собеседования это лотерея. Но мы не можем позволить себе брать миддлов и сеньоров без тестового.
2 — Да, лотерея, но надо заранее чётко понимать, что более менее состоявшиеся мидлы (а уж сениоры тем более) могут плюнуть на слишком долгую задачу и делают это в большинстве случаев. Есть много вариантов, как потратить время интереснее.
Как тогда без траты времени понять, что соискатель нам подходит, и соискателю подходят условия, компания и должность?
Никак, но надо понимать изменения психологии с ростом умений и навыков. Что, фактически, только джуниоры согласны на long-term задачи — они нарабатывают репутацию и опыт. Уже мидл скорее всего подумает: "А оно мне надо? 2-3 дня корячиться? Да ещё и забесплатно? Ну нафиг", но он хотя бы подумает какое-то время. Сениор же подумает: "Да блин, я уже всё всем доказал — ну их лесом с их задачами".
Вам надо как-то заставить захотеть решать эти задачи. Т.е. заставить желать эту работу даже сениору, но у них уже есть сложившееся мнение об индустрии и они требуют индивидуального подхода.
Тут прозвучала хорошая идея — оплачивать тестовые.
Но если человек и за деньги откажется, то наверное ему не нужна работа.
И ещё нужно учесть, что сеньоров на Битриксе днём с огнём не сыщешь. Люди в этой сфере наверное довольно быстро уходят на другие платформы
Но если человек и за деньги откажется, то наверное ему не нужна работа.
И ещё нужно учесть, что сеньоров на Битриксе днём с огнём не сыщешь. Люди в этой сфере наверное довольно быстро уходят на другие платформы
Ну тогда это даже не вопрос найма — если человек не заинтересован в принципе. Но тут опять же выходит мысль, сказанная ранее — к каждому сениору необходимо искать свой подход. Просто потому что там уже немного другие критерии подбора даже на "пойду или не пойду на собеседование".
Тут уже нужно, наверное, как-то заинтересовать его. Скорее уже важно прорекламировать свою компанию, чтобы получить выдающихся людей
В 95% случаях описание данной "рекламы" стандартно до тошноты, банальный пример — узнаёте?
Это настолько надоело сениорам, что проще и разумнее наверное в лоб говорить как то так:
- Есть стэк технологий: А, Б, Ц, Д и всё это вертится на Е
- Есть 4 человека на ПО: один — дятел, а ещё один периодически косячит, но с надеждой на исправление.
- В частях Б и Ц — трэш, угар и содомия — надо упорядочить.
- Код деплоим копи-пастом (что кстати было в том месте, где я работаю сейчас и введение git — законно считаю своим достижением =))
- Тестов нет. Никаких. Ни автоматических, ни хотя бы ручных.
- Менеджера два: один — гуманитарий, а второй вроде что-то шарит. Постить адекватные баги некому.
Надо разгрести — вот тебе зарплата 2000 евро сразу и каждый год поднимаем по 200 евро плюс премии. Чтобы получить премию надо родить ёжика против шерсти, но в целом мне два раза давали.
НЛО прилетело и опубликовало эту надпись здесь
Как тогда без траты времени понять, что соискатель нам подходит, и соискателю подходят условия, компания и должность?
Vasek18, эта процедура давно отработана, прописана в ТК, и называется «испытательный срок».
И не надо со стороны работодателя ждать двух-трёх месяцев, чтобы сказать соискателю: «Извините, Вы нам не подходите». Три дня и — adieu.
То же справедливо и для кандидата.
Как вам такой подход?
Это работает, когда кандидат безработный. Иначе как-то неэффективно: ждешь человека 2 недели, пока он отработает на прежнем месте, принимаешь, оформляешь на испытательный, выдаешь задачи, а потом через три дня — adieu, следущий?
Бывает, что человек берёт на основной работе отпуск на пару дней-неделю.
Правда на позиции серьёзных специалистов я лично такого не припомню, но на позиции от джуниоров до мидлов бывало.
Правда на позиции серьёзных специалистов я лично такого не припомню, но на позиции от джуниоров до мидлов бывало.
Вы ещё не принимаете во внимание необходимость пройти проверку безопасности (у нас нет) и подписать все необходимые договора лично (у нас есть), например, о неразглашении
Логистику трудоустройства кандидата именно в вашей фирме я, разумеется, не принимал во внимание. Но то, что она (логистика) может меняться в соответствии с внутренним регламентом компании (кроме требования оформления ТК и собственно трудового договора) — это точно.
Просто я предложил ещё одну опцию. И, судя по другим комментам, я не одинок.
Просто я предложил ещё одну опцию. И, судя по другим комментам, я не одинок.
Это тоже трата времени и довольно существенная, хоть и оплачиваемая. Плюс человек фактически теряет возможность остаться на текущей работе, так уже ушёл оттуда к началу испытательного периода.
Если конечно не превратить этот испытательный срок в однодневную экскурсию. Человек и с командой познакомится и может быть таск реальный сделает, а на текущей работе просто выходной возьмёт.
Некоторые компании практикуют такой подход и хорошо о нём отзываются и он даже озвучивался в комментариях под этой статьёй.
Если конечно не превратить этот испытательный срок в однодневную экскурсию. Человек и с командой познакомится и может быть таск реальный сделает, а на текущей работе просто выходной возьмёт.
Некоторые компании практикуют такой подход и хорошо о нём отзываются и он даже озвучивался в комментариях под этой статьёй.
Мне нравится этот принцип, сам я с таким встретился однажды лет 5 назад и до сих пор работаю на этом месте. То бишь меня опросили с чем я имел дело, опросили чего я жду от работы… И понеслась.
Этим кстати — решается ещё одна очень важная вещь — проверяется как человек вливается в коллектив. Просто он может писать прекрасный код, но на деле быть несколько неадекватным (для коллектива) и проверочный срок — решает эту проблему. А это, порой, важнее, чем красивый код. Потому что подучить коду или поменять привычные практики профессионал сможет, а вот психологически "не быть говном" — не факт.
А как это чувствуется со стороны кандидата, которому отказывают в итоге? На следующем собеседовании ему придётся объяснять, почему работал где-то неделю или месяц. Смотрится не очень, хотя, может, просто не его профиль оказался.
Спрашиваю потому что приходилось увольнять человека с испытательного срока и было как-то совестно, что испортили ему трудовую.
Спрашиваю потому что приходилось увольнять человека с испытательного срока и было как-то совестно, что испортили ему трудовую.
Как минимум, потому что стоит обращать внимание на прошлый опыт. Github или даже проекты в папочке на флешке. Не столь важно, но почти любой разработчик имеет достаточно большое портфолио. Плевать на NDA, потому что по большому счёту оно ничего не значит, в военке этот код вообще не попадает по гос. тайну (да, да, под гос. тайной параметры кода, тогда как алгоритмы просто всем известны); но даже если каким-то чудом весь код под NDA и у человека физически нечего представить (или он боится), то можно ему просто поверить. Испытательный срок регламентирован трудовым кодексом и приносит намного больше пользы, чем условное тестирование. А за примерами далеко ходить не надо, не так давно пришлось искать работу и в первую же неделю нашёл 4 предложения в практически разных сферах: две военки, один геймдев графики и один геймдиз. Одна военка слилась по времени (так и не перезвонили), другая предложила небольшое тестовое задание на «отсеим дурака», геймдев решил обременить меня рисованием 3D-текста в OpenGL, а геймдиз небольшой анкетой и тремя (!) собеседованиями. В итоге геймдиз не выдержал зарплатной конкуренции, а вот нарисовать 3D-текст я не смог. Это и так не тривиальная задача, а усложнилась она библиотечным адом и мигрированием под linux. В итоге я за час разобрался в API, сформировал 2D-фигуру которую вот хоть рисуй, но потом тупо устал: у меня уже было два предложения, а зарплаты были примерно одинаковые (на военке чуть-чуть меньше, но 100% белая и удобнее местоположение).
По поводу задания, считаю, что добился очень не плохого результата, однако показалось немного грустным выполнение сложной профессиональной задачи за бесплатно, причём в Интернетах не найдёте особых туторов по рисованию 3D-текста. Если что, по условию задачи надо было именно разместить вершины в пространстве, шейдером или ещё чем-то. Это очень неприятный для меня опыт, который никому не пожелаю. Мысли были именно такие, как чуть ниже: «Да блин, я уже всё доказал, ну их лесом». Позвонил, сказал что не справился, после чего позвонил и сказал что согласен. Но уже другим ;) При этом довольно сложная область, это embedded systems со своей спецификой, к тому же увлекаюсь в матан, жаль data science за отсутствием опыта не найти. Думаю на битрексе конкуренция ещё жёстче, да и вы не гугл/яндекс. А так, такие задания это удел студентов (или вчерашних студентов), которым реально нечего делать.
P.S. У вас же есть какая-то статистика по отказам от тестового задания. Довольно интересно, какой процент отказывается от его выполнения? Потому что не первый раз отказываюсь и ничего не теряю, так как всегда были варианты без подобного бреда. И ещё, какие у вас зарплаты, если индивидуально — то какая вилка. И если не секрет, то ваш гонорар интересен ещё более, хотя по статье и имею представление.
По поводу задания, считаю, что добился очень не плохого результата, однако показалось немного грустным выполнение сложной профессиональной задачи за бесплатно, причём в Интернетах не найдёте особых туторов по рисованию 3D-текста. Если что, по условию задачи надо было именно разместить вершины в пространстве, шейдером или ещё чем-то. Это очень неприятный для меня опыт, который никому не пожелаю. Мысли были именно такие, как чуть ниже: «Да блин, я уже всё доказал, ну их лесом». Позвонил, сказал что не справился, после чего позвонил и сказал что согласен. Но уже другим ;) При этом довольно сложная область, это embedded systems со своей спецификой, к тому же увлекаюсь в матан, жаль data science за отсутствием опыта не найти. Думаю на битрексе конкуренция ещё жёстче, да и вы не гугл/яндекс. А так, такие задания это удел студентов (или вчерашних студентов), которым реально нечего делать.
P.S. У вас же есть какая-то статистика по отказам от тестового задания. Довольно интересно, какой процент отказывается от его выполнения? Потому что не первый раз отказываюсь и ничего не теряю, так как всегда были варианты без подобного бреда. И ещё, какие у вас зарплаты, если индивидуально — то какая вилка. И если не секрет, то ваш гонорар интересен ещё более, хотя по статье и имею представление.
Не поверите, но ни одного отказа. Я закладывал в задание возможность достойно «накалять» его за буквально 3 часа. Это не учитывая того, что можно использовать свои наработки и задача совсем не уникальная.
Самым тяжёлым случаем у нас было, когда один соискатель на зп сеньора запросил 10 дней, а потом сдал слабенькую работу. Но тут проблема была в том, Битрикс не был его профилем, буквально 1 проект в портфолио и то считай вёрстка; он уже получал очень неплохие деньги на другом месте, как никак ему было под 40 лет уже. Мы бы не смогли предложить такой же уровень зп и для обоих это был бы проигрыш. Устное собеседовании всё подтвердило и мы могли бы максимум 40к предложить.
В целом я вас понимаю. При одинаковой зп, можно пойти и по пути меньшего сопротивления и выбрать компанию без тестового. И возможно действительно многие так и делают
Самым тяжёлым случаем у нас было, когда один соискатель на зп сеньора запросил 10 дней, а потом сдал слабенькую работу. Но тут проблема была в том, Битрикс не был его профилем, буквально 1 проект в портфолио и то считай вёрстка; он уже получал очень неплохие деньги на другом месте, как никак ему было под 40 лет уже. Мы бы не смогли предложить такой же уровень зп и для обоих это был бы проигрыш. Устное собеседовании всё подтвердило и мы могли бы максимум 40к предложить.
В целом я вас понимаю. При одинаковой зп, можно пойти и по пути меньшего сопротивления и выбрать компанию без тестового. И возможно действительно многие так и делают
НЛО прилетело и опубликовало эту надпись здесь
Кстати, всегда терялся, что прислать, так как что-то тривиальное показывать не хочется, а сложный код в принципе не пишу.
В последние разы присылал домашние проекты, так как использую в них другие технологии и подходы, чтобы с ума не сойти от Битрикса. Но это тоже не очень правильно, так как не показывает мой уровень по основному направлени
Рынок толковых программистов под 1С-Битрикс на столько узкий, что отпугивать их многочасовым тестовым заданием — это просто как-то беспечно. Всякий неадекват на собеседованиях отсеивается после 10-15 минут простого общения и простых технических вопросов. А нормальные программисты всегда заняты, и если они в поиске работы — это означает, что они еще где-то работают и рассматривают как минимум 3 нормальных предложения. Так что если пришел нормальный программист, который нормально ответил на основные технические вопросы, да еще и зарплата его устраивает — это уже повезло.
Вы очень правы, что толковых специалистов на Битриксе очень мало.
Я на самом деле думаю набирать больше джунов, чтобы выращивать их.Лишь бы хотя бы сертификаты какие-то были сданы и знал бы как компоненты подключать. Но таких наверное только фуллстеков брать, так как чистый бек будет долго сидеть без задач иногда
Я на самом деле думаю набирать больше джунов, чтобы выращивать их.Лишь бы хотя бы сертификаты какие-то были сданы и знал бы как компоненты подключать. Но таких наверное только фуллстеков брать, так как чистый бек будет долго сидеть без задач иногда
Учить джунов — так себе выход: те, кто с мозгами, мало-мальским кругозором и минимальными амбициями — быстро поймут, что битрикс — это профессиональный тупик, и уходят. Довольно специфическая мотивация должна быть у человека, чтобы целенаправленно заниматься именно битриксом. Тут либо ставить текучку кадров на конвейер (тоже вариант, много где работает), либо искать вот таких специфических людей — они есть, но их, да, крайне мало.
Спасибо за статью.
Я конечно далек от тим лида, но как веб-разработчик, извлек для себя несколько полезных советов, которые помогут не наступить на грабли, если когда-нибудь попаду в команду.
Я конечно далек от тим лида, но как веб-разработчик, извлек для себя несколько полезных советов, которые помогут не наступить на грабли, если когда-нибудь попаду в команду.
Статья понравилась, надеюсь было полезно почитать про чужой опыт… Поделюсь своим — на кодревью, если вы видите, что одни и те же люди регулярно делают одни и те же косяки и вы вынужденны как обезъяна править одно и тоже — значит люди не тянут сразу исправиться. Нужно и от них побольше усилий получить и задачу облегчить.
Для первого подойдёт разговор с глазу на глаз типа «я с твоими пуллреквестами уже пальцы стёр, давай поговорим, буду голосом рассказывать» и расскажите человеку штук 5 (не больше) самых частых его ошибок… Подробно, чем это мешает, почему это не правильно, ссылки на статьи/стандарты, репродьюсер бага или сравнение по производительности/потреблению памяти… вообщем что угодно, чтобы он ещё неделю твёрдо помнил, что так делать не надо и подсознательно не хотел попасть на новую лекцию… ругать не надо, именно прочитайте лекцию…
А с другой стороны — не надо сразу на всё подряд внимание обращать — русскому/английскому языку вы точно человека не научите через PullRequest&Review, алгоритмы не вобьёте… а вот скобочки расставлять, лесенку делать или пользоваться несколькими библиотечными методами — можете, вот и ограничьтесь только 3-5 косяками (ну если нет чего-то совсем уж тушисвет), но отмечайте их с неотвратимостью автомата и заставляйте править — ошибки уйдут за месяц, а как только не станет этих — можно браться за другие.
Да, время жрёт кучу.
Для первого подойдёт разговор с глазу на глаз типа «я с твоими пуллреквестами уже пальцы стёр, давай поговорим, буду голосом рассказывать» и расскажите человеку штук 5 (не больше) самых частых его ошибок… Подробно, чем это мешает, почему это не правильно, ссылки на статьи/стандарты, репродьюсер бага или сравнение по производительности/потреблению памяти… вообщем что угодно, чтобы он ещё неделю твёрдо помнил, что так делать не надо и подсознательно не хотел попасть на новую лекцию… ругать не надо, именно прочитайте лекцию…
А с другой стороны — не надо сразу на всё подряд внимание обращать — русскому/английскому языку вы точно человека не научите через PullRequest&Review, алгоритмы не вобьёте… а вот скобочки расставлять, лесенку делать или пользоваться несколькими библиотечными методами — можете, вот и ограничьтесь только 3-5 косяками (ну если нет чего-то совсем уж тушисвет), но отмечайте их с неотвратимостью автомата и заставляйте править — ошибки уйдут за месяц, а как только не станет этих — можно браться за другие.
Да, время жрёт кучу.
Скобочки/лесенки хорошо приживляются через code analysis. Вроде как и не лид зануда, а беспристрастная машина при поддержке авторитета сонм разработчиков, разработавших правила.
Мы просто посадили всех на шторм и показали как делать автоформатирование.
На самом деле пока проблем не возникало с форматированием кода. Но если ситуация будет ухудшаться, то я решу её через хуки гита и форматирование через php-cs-fixer. На прошлой работе так делал в качестве эксперимента. В результате все пишут как хотят, а перед коммитом код сам форматируется
На самом деле пока проблем не возникало с форматированием кода. Но если ситуация будет ухудшаться, то я решу её через хуки гита и форматирование через php-cs-fixer. На прошлой работе так делал в качестве эксперимента. В результате все пишут как хотят, а перед коммитом код сам форматируется
К форматированию кода я вообще не придираюсь принципиально. Замечания всегда какие-то логические в духе «убрать запрос в цикле». Если что конкретно запросы в цикле у нас уже никто не делает, просто привёл для примера)
Идея про внушения на созвонах довольно интересная, спасибо
Идея про внушения на созвонах довольно интересная, спасибо
“взяли миддлом/сеньором/старшим — стал миддлом/сеньором/старшим”. Когда я начал искать работу, мне бы хватило и позиции сеньора (и её я искал), но предложение тимлидства меня перекупило и немного польстило.
Процесс взятия лидом не раскрыт. Ведь далеко не всякий лид — сиьер, как и не любой синьер — лид
Правда. Иногда разработчики делают выбор между углублением в разработку и уходом в руководители довольно рано.
На эту позицию у меня было очень интересное собеседование. По сути это был двух часовой разговор в свободной форме про технологии, развитие фирм, команд, про работу по скраму, про Битрикс как про платформу и его альтернативы. Каких-то классических вопросов, типа, что такое позднее статическое связывание не было. Предложение мне сделали довольно быстро, но испытательный срок, конечно, был.
По сути сыграла просто моя готовность и желание быть лидом, так бы меня взяли старшим разработчиком, мб даже с сопоставимой ЗП.
На эту позицию у меня было очень интересное собеседование. По сути это был двух часовой разговор в свободной форме про технологии, развитие фирм, команд, про работу по скраму, про Битрикс как про платформу и его альтернативы. Каких-то классических вопросов, типа, что такое позднее статическое связывание не было. Предложение мне сделали довольно быстро, но испытательный срок, конечно, был.
По сути сыграла просто моя готовность и желание быть лидом, так бы меня взяли старшим разработчиком, мб даже с сопоставимой ЗП.
Смотрю на комментарии, у меня одного что-ли сомнения насчет соответствия названия должности «тимлид» и фактических обязанностей/проделанной работы?
Всегда казалось, что тимлиды появляются в структуре подчиненности тогда, когда появляются относительно независимые команды, с которыми начальник отдела (или департамента) разработки сам уже не успевает управляться.
Мне кажется, вся статья про то как человек с навыками сеньора поставил работу отдела разработки, фактически совмещая обязанности начальника отдела разработки и тимлида.
Всегда казалось, что тимлиды появляются в структуре подчиненности тогда, когда появляются относительно независимые команды, с которыми начальник отдела (или департамента) разработки сам уже не успевает управляться.
Мне кажется, вся статья про то как человек с навыками сеньора поставил работу отдела разработки, фактически совмещая обязанности начальника отдела разработки и тимлида.
О, очень хороший комментарий.
Это одна из причин, почему я писал статью. Должность тимлида довольно туманна и разнится от компании к компании, об этом ещё свидетельствует наличие одной большой конференции почти полностью посвящённой вопросу определения.
В нашей компании я тимлид, хотя по мало чего бы поменялось, если бы должность называлась старший разработчик или технический директор.
Я написал статью, чтобы тимлиды, техдиры, разработчики, hr, руководители, менеджеры увидели мои обязанности и это как-нибудь дополнило их представления. Плюс, чтобы кто-то в комментариях сказал: «это и это не обязанности тимлида, а вот это вот наоборот нужно добавить, да и вообще у нас так: ...». Поэтому мне было очень важно слово «Тимлид» в заголовке.
Это одна из причин, почему я писал статью. Должность тимлида довольно туманна и разнится от компании к компании, об этом ещё свидетельствует наличие одной большой конференции почти полностью посвящённой вопросу определения.
В нашей компании я тимлид, хотя по мало чего бы поменялось, если бы должность называлась старший разработчик или технический директор.
Я написал статью, чтобы тимлиды, техдиры, разработчики, hr, руководители, менеджеры увидели мои обязанности и это как-нибудь дополнило их представления. Плюс, чтобы кто-то в комментариях сказал: «это и это не обязанности тимлида, а вот это вот наоборот нужно добавить, да и вообще у нас так: ...». Поэтому мне было очень важно слово «Тимлид» в заголовке.
Могу посоветовать почитать "Проект Феникс" или еще лучше "Цель", так как раз речь идет о ситуациях похожих на описанную в статье.
Vasek18 большое спасибо за статью! Очень жду продолжения!!!
Если не трудно, проккоментируйте чуть подробнее вот это:
Как много времени у вас это занимает? Возможно, я не правильно представляю кол-во задач у вашей команды, но на первый взгляд это воспринимается как «я пол дня сижу и проверяю задачи и так каждый день».
Вы как-то объясняете клиенту ценообразование работы целиком? Если да, то как вы аргументируете «надбавку» за общение и сдачу?
Спасибо!
Если не трудно, проккоментируйте чуть подробнее вот это:
я ежедневно лично проверяю все оценки и постановку всех новых задач
Как много времени у вас это занимает? Возможно, я не правильно представляю кол-во задач у вашей команды, но на первый взгляд это воспринимается как «я пол дня сижу и проверяю задачи и так каждый день».
во все задачи закладываем время на тестирование, общение и сдачу клиенту
Вы как-то объясняете клиенту ценообразование работы целиком? Если да, то как вы аргументируете «надбавку» за общение и сдачу?
Спасибо!
Как много времени у вас это занимает?
До часа. Хотя я изначально боялся, что действительно по полдня буду сидеть. Но, во-первых, проекты редко меняются и кодовая база по большей части в голове, во-вторых, часть задач нужно просто посмотреть, что есть вся необходимая информация и здесь многое отсеивается, в-третьих, если за примерно 15 минут мы не сможем дать оценку, то мы создаём отдельную задачу под оценку, как, например, интеграция с очередной crm.
Вы как-то объясняете клиенту ценообразование работы целиком?
Ценообразование у нас очень сложное и абстрагирован от этого. Мы индивидуально подошли к каждому клиенту. Но мы и все наши текущие клиенты понимают, что работа над задачей это не только стукание по клаве, но и общение, выработка решения, обсуждение вариантов с клиентом,… Тем более, что с помощью общения мы часто ещё и удешевляем задачу, предлагая альтернативные подходы и подсказывая идеи.
Фишка же не просто время в деньги перевести, а улучшать клиентский бизнес.
Не воспримите как негатив, но: кмк, в большинстве случаев вам просто не хватило воли, чтобы все ускорить и сделать правильно. Например:
1)Инструкции — дать задание, чтобы каждый программист выделял время на их создание до тех пор, пока важных для разработки вещей не будет в электронном виде
2)проблемы с гитом — какие могут быть проблемы? вы же наверняка видели, как и где они работают. Если кто-то не в IDE(а не дай б… в простом текстовом редакторе без автокомплита и поддержкой гита), то путь осваивают и учатся в том же шторме и там же использовать гит. Также не должно быть здоровенных коммитов и длинных задач, если это не исследовательские, используйте композицию
3)«но если твои коллеги саботируют регламенты, работают “по привычке” и не используют новые инструменты» — вы серьезно? перед такими работниками просто надо ставить выбор — либо работаешь с нами, либо досвидос. С вашей стороны, как лида, вы должны периодически общаться с подчиненными, тет-а-тет, особенно, если видите какие-то проблемы в работе. Никаких сюсюканий и детского сада, люди взрослые, ответственность должна быть у каждого!
4)«На два стула не сесть» — и не надо. У каждого есть должностные обязанности, на такие случаи кладется табу, он же болт на тех, кто пытается принудить сесть на эти оба стула
В общем и целом, то, что вы внедряется, вещи хорошие, приучать людей к хорошему надо, не взирая на их текущую зону комфорта(поскольку в итоге вы их пересаживаете в более комфортную зону), но делаете вы слишком мягко, неуверенно что ли… Удачи!
1)Инструкции — дать задание, чтобы каждый программист выделял время на их создание до тех пор, пока важных для разработки вещей не будет в электронном виде
2)проблемы с гитом — какие могут быть проблемы? вы же наверняка видели, как и где они работают. Если кто-то не в IDE(а не дай б… в простом текстовом редакторе без автокомплита и поддержкой гита), то путь осваивают и учатся в том же шторме и там же использовать гит. Также не должно быть здоровенных коммитов и длинных задач, если это не исследовательские, используйте композицию
3)«но если твои коллеги саботируют регламенты, работают “по привычке” и не используют новые инструменты» — вы серьезно? перед такими работниками просто надо ставить выбор — либо работаешь с нами, либо досвидос. С вашей стороны, как лида, вы должны периодически общаться с подчиненными, тет-а-тет, особенно, если видите какие-то проблемы в работе. Никаких сюсюканий и детского сада, люди взрослые, ответственность должна быть у каждого!
4)«На два стула не сесть» — и не надо. У каждого есть должностные обязанности, на такие случаи кладется табу, он же болт на тех, кто пытается принудить сесть на эти оба стула
В общем и целом, то, что вы внедряется, вещи хорошие, приучать людей к хорошему надо, не взирая на их текущую зону комфорта(поскольку в итоге вы их пересаживаете в более комфортную зону), но делаете вы слишком мягко, неуверенно что ли… Удачи!
Спасибо за конструктивность
Я думаю, что как минимум отчасти вы правы по поводу мягкости. Сейчас мы вводим систему штрафов (не денежных) и она саботируется оштрафованными (было бы странно будь наоборот), и тут нужно уже как-то понажимать на коллег.
Проблемы с гитом были для меня вообще шоком. Мы даже экран иногда шарили, чтобы отловить проблемы.
У нас был один парень на Эклипсе и в какой-то момент пришёл сеньор(!) на нотпад++. Все остальные были в шторме, но как мне показалось, один иногда пытался работать через консоль, типа «олдскулл». Парень на Эклипсе правда ушёл уже какое-то время назад, но у него были другие проблемы.
Последней каплей было, когда я увидел пару логов в стиле «решал проблемы с мерджем» на полтора часа. Но тогда до меня уже дошла идея пятничных созвонов и буквально за 2-3 созвона мы пересадили всех в шторм и показали как решать конфликты. Сейчас по крайней мере уже пару месясцев не упоминаются проблемы с мерджами и потерей кода на созвонах, хотя кроме этого больше ничего и не было сделано.
Следующим шагом наверное будут пулл-реквесты
Я думаю, что как минимум отчасти вы правы по поводу мягкости. Сейчас мы вводим систему штрафов (не денежных) и она саботируется оштрафованными (было бы странно будь наоборот), и тут нужно уже как-то понажимать на коллег.
Проблемы с гитом были для меня вообще шоком. Мы даже экран иногда шарили, чтобы отловить проблемы.
У нас был один парень на Эклипсе и в какой-то момент пришёл сеньор(!) на нотпад++. Все остальные были в шторме, но как мне показалось, один иногда пытался работать через консоль, типа «олдскулл». Парень на Эклипсе правда ушёл уже какое-то время назад, но у него были другие проблемы.
Последней каплей было, когда я увидел пару логов в стиле «решал проблемы с мерджем» на полтора часа. Но тогда до меня уже дошла идея пятничных созвонов и буквально за 2-3 созвона мы пересадили всех в шторм и показали как решать конфликты. Сейчас по крайней мере уже пару месясцев не упоминаются проблемы с мерджами и потерей кода на созвонах, хотя кроме этого больше ничего и не было сделано.
Следующим шагом наверное будут пулл-реквесты
По поводу штрафов — отчасти это хорошо, но должны быть не только кнуты, но и пряники.
Про гит — с одной стороны пофиг, кто как работает, но есть устоявшиеся практики работы в IDE, которые облегчают и ускоряют мерж(для того они и написаны). «решал проблемы с мерджем» — после такого надо сразу подходить и давать выбор, либо пересаживаешься на IDE, вот тебе пару дней на освоение, либо на не по пути.
«пулл-реквесты» — а что вам мешало прийти и с первого(ну ладно, хотя бы через месяц) сказать типа: «Все, все работаем по типу гитхаба, используем гит флоу, пока кодревью я не закрою, задача в тест/прод не уходит». Соотв-но, все ваши замечания по кодревью будут устраняться, иначе задача будет превышать сроки. Демократия и равенство в коллективе хорошо, когда самостоятельность/проактивность и отвественность каждого не «на дне», а покамест вы начальник этого стада. Вот когда воспитаете подопечных, то можно будет и подкармливать «печеньками». Но только эти печеньки заранее озвучить, возможно для каждого свою, чтобы была прозрачность и мотивация.
Про гит — с одной стороны пофиг, кто как работает, но есть устоявшиеся практики работы в IDE, которые облегчают и ускоряют мерж(для того они и написаны). «решал проблемы с мерджем» — после такого надо сразу подходить и давать выбор, либо пересаживаешься на IDE, вот тебе пару дней на освоение, либо на не по пути.
«пулл-реквесты» — а что вам мешало прийти и с первого(ну ладно, хотя бы через месяц) сказать типа: «Все, все работаем по типу гитхаба, используем гит флоу, пока кодревью я не закрою, задача в тест/прод не уходит». Соотв-но, все ваши замечания по кодревью будут устраняться, иначе задача будет превышать сроки. Демократия и равенство в коллективе хорошо, когда самостоятельность/проактивность и отвественность каждого не «на дне», а покамест вы начальник этого стада. Вот когда воспитаете подопечных, то можно будет и подкармливать «печеньками». Но только эти печеньки заранее озвучить, возможно для каждого свою, чтобы была прозрачность и мотивация.
Мы очень хотим ввести «пряники», но к сожалению пока было не из чего их делать. Именно по этой причины мы решили ввести «кнуты», потому что все деньги на премии уходили на оплату работ, которые не оплачивал клиент, если точнее, на переработки по задачам.
Мы решили ввести какие-то наказания, потому что одни и те же люди, регулярно превышали свои же оценки или растягивали часовую задачу на весь день.
Мы сразу же обсудили, что не будем штрафовать деньгами, потому что как минимум пока не можем ими поощерять. В качестве штрафов мы решили ввести обязательные доклады/лекции, которые хотя бы косвенно относятся к причине превышения.
К сожалению, недостаток времени. Каждый программист писал код практически по 8 часов (минус созвоны), в том числе и я. И всё равно не успевали.
Сейчас вроде бы стало полегче. Думаю попробовать ввести практику совместных кодревью в конце дня.
Да и если быть честным, то на Битриксе трудно писать совсем уж плохой код.
Мы решили ввести какие-то наказания, потому что одни и те же люди, регулярно превышали свои же оценки или растягивали часовую задачу на весь день.
Мы сразу же обсудили, что не будем штрафовать деньгами, потому что как минимум пока не можем ими поощерять. В качестве штрафов мы решили ввести обязательные доклады/лекции, которые хотя бы косвенно относятся к причине превышения.
а что вам мешало прийти и с первого(ну ладно, хотя бы через месяц)
К сожалению, недостаток времени. Каждый программист писал код практически по 8 часов (минус созвоны), в том числе и я. И всё равно не успевали.
Сейчас вроде бы стало полегче. Думаю попробовать ввести практику совместных кодревью в конце дня.
Да и если быть честным, то на Битриксе трудно писать совсем уж плохой код.
потому что все деньги на премии уходили
И тут мы приходим к тому, что либо ваши сотрудники некомпетентны и не умеют планировать свое время(в этом случае возможно стоит пересмотреть материальное вознаграждение, а также делать декомпозиции задач, если они реально большие), либо сотрудник не понимает или не хочет понимать, что он приносит деньги, а не просто кодит и хабр читает(тут либо расставаться, либо проводить беседы)
в том числе и я
В смысле вы? Вы же устроились тимлидом, вот и тимлидьте, не лезьте на «второй стул». А так вы только распыляетесь, а картину видите только с опозданием, потому и времени на правильные решения уходит много
И тут мы приходим к тому, что либо ваши сотрудники некомпетентны и не умеют планировать свое время
Задачи всегда декомпозированы, конечно. Иначе они превращаются в эпик.
Считаю, что нет ничего более демотивирующего, чем денежные штрафы на работе или понижение ЗП. Поэтому решаем проблему развитием кадров и пробуем разные подходы для этого. Увольнять пока не приходилось и, слава богу, сейчас нет таких кандидатов
В смысле вы? Вы же устроились тимлидом, вот и тимлидьте, не лезьте на «второй стул».
Да, я упомянул этот момент в статье. Про два стула
Но в любом случае полностью переставать программировать я, наверное, не буду
сама разработка тоже была не ахти:
где-то что-то разрабатывалось даже вне гита
Скажите, как вы определили, что команде нужна децентрализованная система контроля версий, а не что-то иное с master репозиторием? Что-то кроме «ну все же используют гит, и это все знают»? Это связано с workflow именно этой команды?
Нужно просто не терять код, не перезаписывать чужие правки на проекте, работать изолировано и иметь актуальную кодовую базу, хранить устаревший код для справки, знать, кто что исправил и зачем, хранить удалённую копию кода на случай выхода человека/компьютера из строя. Как тут без гита с удалённым репозиторием?
Нужно просто не терять код… иметь актуальную кодовую базу, хранить устаревший код для справки, знать, кто что исправил и зачем,
выполняется и централизованными скв.
не перезаписывать чужие правки на проекте
Почему? Любая правка может быть перебита новой правкой. Как было до — для этого есть неизменяемая история.
работать изолировано
Часто приходится переключаться с задачи на задачу, бросая на полдороге?
хранить удалённую копию кода на случай выхода человека/компьютера из строя.
Опять же, это позволяет любая скв.
Мне кажется у нас недопонимание
В данном случае не значит, что использовалась какая-то другая система. Тут говорится про проект, где был один сервак на всех и программисты по очереди правили файлы, подключаясь по фтп. То есть не было вообще никакой скв, программисты просто правили файлы в надежде, что сервак не будет крашится и всё.
где-то что-то разрабатывалось даже вне гита
В данном случае не значит, что использовалась какая-то другая система. Тут говорится про проект, где был один сервак на всех и программисты по очереди правили файлы, подключаясь по фтп. То есть не было вообще никакой скв, программисты просто правили файлы в надежде, что сервак не будет крашится и всё.
Ну так если бы было сказано «программисты даже не использвали систему контроля версий!» — вопросов бы не было. Была названа конкретная система — «что-то разрабатывалось даже вне гита». «Гит» пока что — не имя нарицательное, это название конкретной системы конкретного вида. Поэтому я и спроил — отчего речь именно о гите, а не, скажем, svn или чем-то аналогичном.
Хорошая статья. Пишите еще.
Практически один в один как у нас в отделе разработки.
Мы также пытаемся внедрить scrum.
Как вы с разработчиками оцениваете время реализации задач в спринте?
Практически один в один как у нас в отделе разработки.
Мы также пытаемся внедрить scrum.
Как вы с разработчиками оцениваете время реализации задач в спринте?
Ну и самое главное хотя-бы в относительных величинах, насколько тимлид зарабатывает больше программиста?
Используйте ли в PhpStorm учет времени и интеграцию с Jira? Там учет времени это не только возможность выгружать реальное время, но и сохранение контекста задачи (набор открытых файлов).
Про неоплачиваемое тестовое задание… Мой опыт показывает, что есть смыл только для джунов. Мидл и выше по хорошему уже должен понимать ценность своего времени. Кандидату который рассматривает несколько компаний делать тестовое в каждую из них потребует уже не пару вечерочков. Кроме того, за пару вечеров можно написать примитивный код зачастую являющийся примером плохих практик и реальном проекте так бы человек писать не стал. Но своими пару вечерами вы заставляете его либо потратить много времени, либо написать плохой код. И что вам покажет результат такого тестового? Ничего. Ни по софт скилам, ни по техническому уровню. Тут в комментариях уже писали, что минут 20 личной беседы и уже понятно без всякого тестового задания.
Про неоплачиваемое тестовое задание… Мой опыт показывает, что есть смыл только для джунов. Мидл и выше по хорошему уже должен понимать ценность своего времени. Кандидату который рассматривает несколько компаний делать тестовое в каждую из них потребует уже не пару вечерочков. Кроме того, за пару вечеров можно написать примитивный код зачастую являющийся примером плохих практик и реальном проекте так бы человек писать не стал. Но своими пару вечерами вы заставляете его либо потратить много времени, либо написать плохой код. И что вам покажет результат такого тестового? Ничего. Ни по софт скилам, ни по техническому уровню. Тут в комментариях уже писали, что минут 20 личной беседы и уже понятно без всякого тестового задания.
Не слышал об этой интеграции. Могли бы вы рассказать подробнее. В списке плагинов не увидел ничего по маске «jira»
Ну первым делом сначала идёт беседа. Это один из уровней фильтрации. Плюс вдруг соискатель расскажет что-то такое, что мы ему и тестовое не дадим, а сразу возьмём
Но в Битриксе нужно знать очень много специфических вещей, а код у Битриксоидов часто можно назвать «не очень», хотя это просто «стиль Битрикса», поэтому чаще всего решения пограничны
Ну первым делом сначала идёт беседа. Это один из уровней фильтрации. Плюс вдруг соискатель расскажет что-то такое, что мы ему и тестовое не дадим, а сразу возьмём
Но в Битриксе нужно знать очень много специфических вещей, а код у Битриксоидов часто можно назвать «не очень», хотя это просто «стиль Битрикса», поэтому чаще всего решения пограничны
Если у человека есть мотивация устроиться именно к вам в фирму — он тестовое задание напишет. Я не согласен, что это плохой инструмент.
На собеседовании можно многое узнать о человеке, о его подходе к решению задач, знании языка и т.д. Но как человек кодит в реальной жизни понять сложно, краткие задачи типа сортировки массива этих знаний не дадут. Другое дело, что задание может быть не слишком большим: подробности можно дополнительно разобрать на втором собеседовании, и просто пройтись по тому, что ещё можно было бы сделать, а что можно было бы архитектурно изменить, если бы у испытуемого было больше времени.
Я один раз брал на работу человека, о котором после собеседования осталось впечатление «скорее не брать», однако в итоге с радостью взял, увидев его задание.
То что дефицитные специалисты могут отказаться делать тестовое задание — это не значит, что оно плохо для оценки способностей. Кстати, оплата за задание не факт что выход, разве что небольшая дополнительная мотивация.
На собеседовании можно многое узнать о человеке, о его подходе к решению задач, знании языка и т.д. Но как человек кодит в реальной жизни понять сложно, краткие задачи типа сортировки массива этих знаний не дадут. Другое дело, что задание может быть не слишком большим: подробности можно дополнительно разобрать на втором собеседовании, и просто пройтись по тому, что ещё можно было бы сделать, а что можно было бы архитектурно изменить, если бы у испытуемого было больше времени.
Я один раз брал на работу человека, о котором после собеседования осталось впечатление «скорее не брать», однако в итоге с радостью взял, увидев его задание.
То что дефицитные специалисты могут отказаться делать тестовое задание — это не значит, что оно плохо для оценки способностей. Кстати, оплата за задание не факт что выход, разве что небольшая дополнительная мотивация.
Спасибо за статью, это самая полезная вещь, которую я прочитал сегодня. И комменты под ней не уступают по полезности.
Хочу прокомментировать один момент, с которым лично столкнулся много раз и вразных проектах:
Раз явных протечек не было, то второй список почти не имеет смысла — это просто жизнь / неопределенность / законы Мерфи. Его можно составлять на предмет анализа повторяемости, но с ним поделать ничего нельзя — проблема старая, как трактаты Сунь-Цзы.
Если занимаетесь взаимосвязанными задачами (и, в идеале, используете ганта), а не чистым хаосом типа разгребания багов из helpdesk, то мне помогает прием из ТОС (это который Голдратт / Цель и т.п.). Суть в двух словах проста — пусть все дают самую минимальную оценку для своих задач в идеальных условиях (если не отвлекают, ничего не отваливается, все доступы есть и т.п.). Это важный момент и он придет не сразу (!) — надо донести и донести(!) мысль, что это не обязательство и вообще завершение задачи в эти сроки вы не ждете — на то они и идеальные. Более того, если человек в эти сроки регулярно укладывается, то он явно не отдал всю подстраховку и с ним надо серьезно побеседовать.
Эти оценки пишете в ганта, получаете идеальную / нереальную дату завершения. Дальше к ней в конец добавляете «буфер проекта» — рекомендую начать с равного 100% критического пути. Если получили очень поздний дедлайн — значит либо народ не сдал в общий котел личные подстраховки, либо вы ставите нереальные дедлайны )).
Перед всеми боковыми ветками по той же схеме добавляете «боковые буферы» и определяете промежуточные дедлайны для второстепенных задач. Теперь вся неопределенность и риски будут пожирать время из буферов, вам остается направлять все усилия только на те задачи, которые пожирают буфер быстрее, чем продвигаются. Т.е. задача на 4 дня, которая съела 3 дня из буфера — ok. Задача на 1 день, которая съела 2 из буфера — НЕ ok. Плюс в том, что уже на первой трети проекта усилия и внимание автоматом будут на самых проблемных местах и есть шанс закончить без ночных бдений.
Конечно, это не так хорошо работает в коротких спринтах, на длинных проектах эффект очевидней. Но если научите давать оценку времени без учета подстраховки — это здорово вам поможет при любых принципах управления.
Хочу прокомментировать один момент, с которым лично столкнулся много раз и вразных проектах:
Мы оооочень много думали над проблемой КПД. Явных протечек видно не было:
программисты оценивали задачи довольно здраво
реально над ними работали, а не просто ставили таймер
с коммуникациями не было никаких проблем
Но потом всегда что-то шло не так и каждый раз разное:
находился подводный камень
итоговое решение не устраивало клиента
отваливался какой-то смежный функционал
при тестировании что-то пропускали и потом переделывали
теряли время на поиск каких-то доступов
…
Раз явных протечек не было, то второй список почти не имеет смысла — это просто жизнь / неопределенность / законы Мерфи. Его можно составлять на предмет анализа повторяемости, но с ним поделать ничего нельзя — проблема старая, как трактаты Сунь-Цзы.
Если занимаетесь взаимосвязанными задачами (и, в идеале, используете ганта), а не чистым хаосом типа разгребания багов из helpdesk, то мне помогает прием из ТОС (это который Голдратт / Цель и т.п.). Суть в двух словах проста — пусть все дают самую минимальную оценку для своих задач в идеальных условиях (если не отвлекают, ничего не отваливается, все доступы есть и т.п.). Это важный момент и он придет не сразу (!) — надо донести и донести(!) мысль, что это не обязательство и вообще завершение задачи в эти сроки вы не ждете — на то они и идеальные. Более того, если человек в эти сроки регулярно укладывается, то он явно не отдал всю подстраховку и с ним надо серьезно побеседовать.
Эти оценки пишете в ганта, получаете идеальную / нереальную дату завершения. Дальше к ней в конец добавляете «буфер проекта» — рекомендую начать с равного 100% критического пути. Если получили очень поздний дедлайн — значит либо народ не сдал в общий котел личные подстраховки, либо вы ставите нереальные дедлайны )).
Перед всеми боковыми ветками по той же схеме добавляете «боковые буферы» и определяете промежуточные дедлайны для второстепенных задач. Теперь вся неопределенность и риски будут пожирать время из буферов, вам остается направлять все усилия только на те задачи, которые пожирают буфер быстрее, чем продвигаются. Т.е. задача на 4 дня, которая съела 3 дня из буфера — ok. Задача на 1 день, которая съела 2 из буфера — НЕ ok. Плюс в том, что уже на первой трети проекта усилия и внимание автоматом будут на самых проблемных местах и есть шанс закончить без ночных бдений.
Конечно, это не так хорошо работает в коротких спринтах, на длинных проектах эффект очевидней. Но если научите давать оценку времени без учета подстраховки — это здорово вам поможет при любых принципах управления.
ИМХО это хорошо работает на больших объемах — там в любом случае хороша любая приблизительная оценка, и она будет всегда +-200% :)
При более детальном планировании (как раз на уровне спринта) мне больше нравится учитывать риски от девелоперов. Потому что на нашем проекте бывают тривиальные откатанные задачи, по ним можно смело брать идеальную оценку без подстраховки вообще, и вкладываемся. А бывает девелоперы видят возможные риски, и тогда надо добавить чуть больше.
При более детальном планировании (как раз на уровне спринта) мне больше нравится учитывать риски от девелоперов. Потому что на нашем проекте бывают тривиальные откатанные задачи, по ним можно смело брать идеальную оценку без подстраховки вообще, и вкладываемся. А бывает девелоперы видят возможные риски, и тогда надо добавить чуть больше.
А это и работает лучше на больших объемах. На маленьких сами издержки планирования могут быть выше возможного выигрыша. Но, по опыту, если с этими принципами пройти 2-3 больших проекта, то и маленькие идут быстрее — команда понимает, что в свои оценки риски закладывать не нужно — риски заложит менеджер или тимлид.
Спасибо за отзыв и комментарий
Немного не понятно в чём выгода работы с минимальной оценкой и буфером в сравнении с работой с оценкой с рисками от самого программиста?
Например, если он просто всегда будет говорить 1 час?
Немного не понятно в чём выгода работы с минимальной оценкой и буфером в сравнении с работой с оценкой с рисками от самого программиста?
Например, если он просто всегда будет говорить 1 час?
Для изолированных задач не имеет смысла, а вот для связанных смысл большой. Одна из ключевых выгод в том, что каждый интуитивно закладывает одни и те же или схожие риски. У кого-то один риск сыграет, у кого-то другой, но каждый указал время своей задачи с учетом большинства известных рисков.
И тут срабатывает студенческий синдром — если срок назван, то очень маловероятно, что задача будет закончена раньше — даже если риск не сработает, заложенные излишки времени уйдут в лучшем случае на полировку решения или еще какой-нибудь перфекционизм.
А так — все риски собраны в один большой риск (буфер) и стоят в нужном месте, защищая дэдлайн. И схожие риски не дублируются.
И тут срабатывает студенческий синдром — если срок назван, то очень маловероятно, что задача будет закончена раньше — даже если риск не сработает, заложенные излишки времени уйдут в лучшем случае на полировку решения или еще какой-нибудь перфекционизм.
А так — все риски собраны в один большой риск (буфер) и стоят в нужном месте, защищая дэдлайн. И схожие риски не дублируются.
Зарегистрируйтесь на Хабре , чтобы оставить комментарий
Работа тимлидом в 2018-ом году