Комментарии 168
Спасибо за статью. И сразу вопрос про:
Это удобно тем, что временные затраты на найм снижаются лишь до поиска подходящих резюме и лёгкого интервью с соискателями для проверки на адекватность и рассказа про тестовое задание, и, конечно, непосредственно проверки задания.
На хабре уже же обсуждалось, что подобный подход отсеивает людей, которые:
- Семейные и не хотят думать о коде дома. Они пропустят вашу компанию.
- Имеют статьи, полезные проекты на github. Они просто потратят вечер на свой проект и уйдут к другим.
- Серьезно работающих. У них сначала не будет времени, а потом они не захотят вам писать, так как будет впечатление что "легкое тестовое задание человек делал уж неделю, наверное туп как пробка". Вы можете так не думать, однако специалист будет считать, что менеджеры среднего звена именно так и будут думать о нем.
=====
Другой вопрос: а вы сами стали бы решать задачу? Несложную, на middle уровень, например, lock-free алгоритм очереди с возможностью итерирования и т.д.?
=====
друг фронт, который в то же самое время начал подумывать уйти с фриланса, поэтому мы смогли быстро заткнули вакансию, а я получил премию за приведение сотрудника
Считаете ли вы это коррупцией или кумовством, что наняли в свою команду друга? Был ли при найме конфликт интересов? Он тоже решал задачу, или так взяли?
=====
Какую часть своего времени вы программирует? И как вы все-таки считаете, вы уже менеджер среднего звена, или же еще team lead?
=====
Ещё очень вредны моменты, когда люди отказываются брать на себя ответственность.
А какая премиальная часть за взятие ответственности? Если ноль, то рациональнее не брать ответственность. А если берут — то нет ли проблемы с работой, если, как мы видим, люди явно поступают иррационально с проектом?
=====
Как вы решаете проблему с недоверием сотрудникам к вам?
Про тестовое задание
Собеседование и тестовые обсуждались уже множество раз в том, числе и на Хабре. И у всех подходов есть свои минусы. Самым оптимальным, честным, точным, наверное, можно считать приглашение на целый день в офис, где соискатель будет работать, так как будто бы он уже часть команды. Но даже он имеет проблемы с теми пунктами, которые вы описали. Например, серьёзно работающий человек не сможет найти целый день на работу на другую фирму.
Я считаю, что в конкретно нашем случае тестовое задание очень важно, так как Битрикс требует очень много специфических знаний.
Плюс Битрикс в 80% случаев подразумевает разработку интернет-магазинов и довольно скучные задачи, поэтому считаю нечестным перед кандидатом проверять его общие знания и логику, а потом давать какие-то однотипные задачи. Поэтому тестовое задание по сути является разработкой формы заказа и у соискателя есть лишний шанс подумать хочет ли он заниматься этим 40 часов в неделю, так как не всем такое по душе.
Сам я бы решал тестовые задачи, что собственно и делал некое количество раз
Про друга
Тут выгода для меня/нас была в том, что, во-первых, я мог очень быстро связаться с соискателем и доступно объяснить, а, во-вторых, я успел с ним сделать несколько проектов и уже знал его уровень.
Но чтобы избежать кумоства и чего-либо подобного, я не принимал никакого участия в его собеседовании и принятии решения о приёме на работу. Но это частный случай нашей компании. Наш директор имеет довольно уверенные технические знания, поэтому он мог принять решение самостоятельно.
Про самоощущение
На сегодняшний момент где-то половину своего времени я пишу код, как рядовой программист, считаю это важным для себя и компании. Остальное время по большей части тоже «техническое»: код-ревью, консультации ребят, оценки задач, выбор подходов. Поэтому считаю себя лидом, а не менеджером.
Про ответственность
На самом деле всё начинается с таких вещей как «Этот код писал не я, я его не буду править», «Я решил не подключать библиотеку А, так как думаю, что это не в моей компетенции», «У меня на тесте не повторилась ошибка, на бою не буду трогать админку»,…
Довольно эфемерный момент для «начисления очков», поэтому премирования нет.
Сам я борюсь с этими стопами через разрушение мифов и страхов у ребят.
Про недоверие
На самом деле не сталкивался с этой проблемой.
Но во второй части расскажу поддержание авторитета. Довольно интересный момент
Проблема с тестовым заданием обычно всего одна — оно должно быть оплачиваемым по полноценному рейту. Тогда соискатель с удовольствием его выполняет (особенно с собственной оценкой времени))).
Это одновременно и сдерживает работодателя от раздутых заданий, и позволяет соискателю спокойно показать свой уровень без нервотрепки и стресса ("я на них три дня потратил, а они мне отказали").
Нужно будет обсудить внутри фирмы.
Так по идее можно и переманивать людей
На одном из собеседований на удалёнку, когда мне предложили сделать тестовое задаение, я прямо сказал: бесплатно делать не буду. После чего мы обсудили критерии приёмки, стоимость и сроки. Результатом стало долгое плодотворное сотрудничество.
Собственно я бы хотел соискателеям дать совет: уважайте себя и цените своё время, адекватный работодатель это оценит, а не адекватный… а он вам нужен?
Также добавлю, что пройдя 100+ собеседований в разных компаниях (как успешно, так и не успешно, с согласие на работу, так и с отказом на работу после приглашения), а также при проведении собеседований хотя бы несколько десятков раз, вырабатывается навык, когда в течении 15 мин или меньше точно можешь сказать, что тебе сотрудник/компания не подходит, а еще за 30-45 мин понять-допускать к испытательному сроку/идти на испытательный срок или нет.
За 30-45 мин как раз идет диалог-что делали, как решали проблемы и т д и т п, т е даже без тестов-просто в режиме свободного диалога.
Все остальное, особенно задачи на более, чем 2 часа должны быть уже на испытательном сроке, где стороны обоюдно присматриваются друг к другу, а не одна из сторон (часто этот маленький, но важный момент забывают и сами работодатели).
Если работать надо в команде, то обязательно на собеседовании кроме руководителя должен быть 1-2 сотрудника из команды, с которыми чаще всего нужно будет взаимодействовать, чтобы коллеги определили (да и сам кандидат) для себя на сколько подходит человек в плане коммуникаций, знаний и нет ли интуитивного отторжения или еще чего.
Вот и все
А минусы есть по обеим сторонам, важно понять на какие компромиссы и уступки можно пойти и что можно улучшить опять же с обеих сторон, т к предела в совершенстве нет.
Вы проходили собеседования больше 100 раз?
За 6+ лет своей ппофессиональной деятельности да, т к это мое хобби и в среднем хожу на собеседование 2-3 раза в
месяц
Я в одно и тоже место редко хожу
Компаний много от мало до велико и необязательно IT, где нужна разработка теже кредитные органтзации, логистика, торговля и т д и т п
Компаний тьма
Все в основном через spb.hh.ru, реже через знакомых и еще реже через Хабр и Гитхаб
Какие обиды?
Это рынок и обе стороны рискуют
И если брать в целом, то можно вывести жизненный цикл жизни специалиста в рамках одной компании или одного проекта, которая заключается в определенном стеке технологий, предметной области, подходах к разработке, поддержке и оптимизации.
Данный цикл длится по разному, но обычно составляет 1, 3 или 5 лет, реже 10 лет, т к более 5-ти лет находится в одном проекте или более 10-ти лет вариться в одной предметной области чревато для компетенций относительно рынка.
И не стоит забывать, что профессия-это еще и хобби и страсть к познанию, а работодатель-это спутник и инструмент, позволяющий знания применить в практике. Итого: Вы выбираете себе удобный и нужный инструмент, исходя из Ваших пожеланий и потребностей профессионального роста, равно как и работодатель выбирает себе более подходящего по его мнению сотрудника.
С компанией, которая чего-то боится мне не по пути, равно как и сотруднику, который боиться вырваться из зоны комфорта сложно осознать, что все на самом деле очень просто и нет ничего сложного.
На счет количества вакансий-напр, .NET или MS SQL в spb.hh.ru наберите поиск и каждую неделю там новые вакансии и их в среднем сотни за месяц от нескольких десятков компаний, а за год-более сотни таких компаний. И потому 100 компаний за 6+ лет это еще немного (по крайней мере исходя из статистики). Но все охватить-такой цели не стоит. Однако, если хочешь держать руку на пульсе, что происходит на рынке, как не нужно проводить собеседование, анализировать и понимать что от тебя хотят и что скрывается в несказанности рекрутером, то считаю просто необходимостью походить по собеседованиям (особенно тем, кто проводит эти собеседования и сидит на месте более 10-ти лет). Лишним не будет точно, а за частую и полезно в развитии как коммуникабельных способностей, так и телепатических)
Да и к тому же, частотбывает, что ты хочешь в компанию, но тебе отказывают либо сразу, либо на последнем этапе собеседований. И сколько таких ситуаций было-я же не обижаюсь.
Грамотный работодатель не заканчивает процедуру поиска, пока не начнется по факту первый рабочий день нового сотрудника, и у работодателя всегда есть в заначке еще кандидаты в случае непрохождения новым сотрудником испытательного срока (инициатива может быть как от работодателя, так и от сотрудника-не стоит и этот момент забывать).
Агалогично и у специалиста должны быть запасные варианты (правда здесь немного похуже, т к единицы из компаний понимают эту необходимость, а большинство просто обижаются или боятся раз их оставили в заначку)
На счет увольнений-здесь не такой большой опыт (всего несколько раз, а не десятки), однако конечно если решили сами уволиться, то работу нужно довести до логической точки и заранее в фоне подготовить почту для быстрой передачи знаний, а также сообщить работодателю о своем решении как можно раньше, а не за 2 недели, чтобы и у того было время откорректировать рабочий процесс с учетом Вашего ухода.
Также можно оставить отзыв о работодателе и договориться о рекомендациях Вам.
Правда уже несколько лет не ходил никуда
а вы сами стали бы решать задачу?
Что и показывает, что компания должна реально оценивать свой уровень. В Амазоне — да, в местной конторе — нет. Если место интересное и хочу эту работу — я делал.
По статистике, мы сообщали кандидатам о тестовом задании после первого разговора. На больше сотни кандидатов, было пару недовольных (одного при этом наняли) но всего пару несделанных заданий и ни одного явного отказа делать.
Считаете ли вы это коррупцией или кумовством, что наняли в свою команду друга?
Бонус всегда приятен, да и определенные усилия со своей стороны есть :)
А серьезно, если речь не про госконтору, то главное результат. Если человек полезен команде, то и я, и команда, и руководство заинтересовано, чтобы нанять наиболее комфортного мне как тимлиду человека. Потому если я на 100% уверен — посоветую так что друга возьмут. Но это палка о двух концах — если не сработает, то доверие ко мне будет серьезно подорвано, потому я тут осторожен.
Бонус в данном случае вторичен, но опять таки если начальство устраивает — то почему бы и нет?
А какая премиальная часть за взятие ответственности? Если ноль, то рациональнее не брать ответственность.
Премии не всегда должны быть деньгами. Правильная похвала тоже работает. Сотрудники хотят понимать, что лид их ценит и доверяет. Опять таки это повышает шансы на развитие или хотя бы на неувольнение при сокращении бюджета.
Ну и далее дополнительные вещи — команда и менеджмент в целом гораздо терпимее к ошибкам того, кто берет ответственность и делает результат. А ошибки бывают у всех. Ну и вообще быть на хорошем счету у руководства выгодно.
На хабре уже же обсуждалось, что подобный подход отсеивает людей, которые
В контексте все правильно:
Итого в разработке сложилась следующая ситуация:
один “старичок”
я
трое абсолютных новичков
работа ещё не налажена
часть знаний уже потеряна
Ибо что это за новички, что нос воротят от тестового задания — в топку их.
Блин, тоже пишу статью, но скорее про собеседования, коллег и управление, чем про себя.
Я скорее архитектор/тех.дир, нежели разработчик.
В свое время понял, что больше всего меня не устраивало в компании именно руководство и как бы я не любил разработку, как бы не вертелся на пике bleeding-edge и не ценил объективно низкий уровень реальной конкуренции, определенно было ощущение, что занимаюсь чем-то не тем.
Добили собеседования после смены компании, некомпетентность начальства, ведущих разработчиков(именно как руководителей) уже на этом этапе бросается в глаза.
В итоге пришел на проект с ужасающей архитектурой, безопасностью и тратами на разработку, но зато все по методологиям, менеджер мог расписать каждые 10 минут. Стал ведущим разработчиком, затем тех.диром, а потом ушел, но определился со своей ролью на будущее.
Сейчас, для маня главное — прозрачность, стресс порождается ее отсутствием. Например, если предложенные тесты на вакансии проверяют только на стрессоустойчивость(например простые задания, или задания на запоминание википедии), от них выгодней открыто отказаться ( написать, что задач не будет). Любые правила и защита — автоматизируемы, если правило нельзя автоматизировать и нет ответственного лица — оно не служит для защиты, а следовательно — устраняется.
Я искренне ценю мысли, подобные вашим впечатлениям из части "Чему я научился..." и так же искренне желаю вам не предавать эти убеждения и расти, как в разработке, так и руководстве.
Я провёл свои первые полгода с уклоном в руководство и каждый месяц очень многому учусь. Больше всего надеюсь, что команда под моим началом будет развиваться, особенно в индивидуальном плане каждый из коллег
В последнее время я тоже думал о переходе разработчиков на пулл-реквесты, может быть проведу эксперимент хотя бы на одном проекте.
Но мы сейчас активно расширяемся, плюс сами ребята быстро растут в профессиональном плане, а также на проектах большое количество подрядчиков (сеошники, 1сники, контент-менеджеры, ..), так что возможно закреплю по человеку на проект и тоже пулл-реквесты.
Хм, крутая идея. Нужно будет подумать над
Хотя бы ревьюить мой код. Его сейчас никто не смотрит. И ребята пока не ревьюят код коллег. Как раз для передача знаний это чуть ли не основная выгода здесь
Pull-реквесты очень сильно повысили качество у нас.
Что используем: TFS + git, основные ветки имеют полиси — мерж только через пулл-реквест, с билдом и привязанными тасками. Билд, понятное дело, с тестами и линтером. Более медленный статический анализ и UI-тесты проходят ночью. Есть формальный чеклист для ревьювера — проверить закрытие задачи, репортинг времени, тесты, документацию — то что пока не смогли автоматизировать. Отключать полиси имеет право только техлид и никогда (почти) этого не делает (это к вопросу о доверии — техлид работает в тех же условиях).
Перед релизом QA команда смотрит список фактически попавших в билд задач (вот это очень хорошо сыграло, перестали пропускать недоделки и забытые вещи). И проверяет что ночной билд зеленый. Даже если не зеленый, всегда понятно можно ли релизить.
ИМХО есть огромная разница между «иногда я делаю код-ревью» и «каждая строчка кода обязательно проходит ревью». За один день ревью перестает восприниматься как придирка и становится частью процесса.
два одинаковых работника, но один из них читает профессиональную литературу и/или ведёт личные проекты, а второй нет.
Вы действительно считаете что после того как человек проработал 8 часов за день, потратил еще 2 часа на дорогу приедет домой и у него будет здоровое желание повести личный проект?
И, кстати, с этими мыслями мы ввели добровольно-принудительное обучение в рабочие, оплачиваемые часы.
Но к оправданию людей с проектами, у нас таких как минимум двое (Мы не поднимаем этот вопрос из-за этических соображений). У одного проекты на Андроиде, у другого на Ларавеле. Так что это как хобби получается.
В общем-то, логично… Наличие личных проектов может говорить о том, что у человека нет личных/домашних проблем, которые жрут время и нервы, а также о том, что состояние выгорания ему в данный момент не угрожает. Плюс, сторонние проекты в смежных областях могут быть неплохим источником свежих идей.
Кстати, да. Эти же ребята ещё и самые спокойные и стрессоустойчивые
Я, вообще, думал, что причина в свежих идеях, потому что один парень вырос за несколько месяцев с миддла до сеньора по моему имхо и один из немногих, кто использует ООП вне взаимодействия с D7
Кстати, опыт показал, что миддл может использовать D7 очень хорошо. Проблема как раз в том, что чтобы писать на Битриксе на 5+ не нужно быть очень крутым программистом из-за компонентного подхода и любви Битрикса к «портянкам» кода. Да и D7 плохо продокументирован и не все решения в нём мне нравятся.
В вашем случае, если человек будет хорошо писать код, отвлечённый от D7, с нуля, например, что-нибудь связанной с апи от/для стороннего сервиса, то он уже не джун.
Но опять же, у меня занимает сколько-то недель код-ревью и общения, чтобы понять уровень разработчика
Они реально забирают ментальные силы и желание работать. Особенно, если у тебя есть жена/дети/девушка/друзья/..., которые вечером ждут твоего внимания.
Единственный способ борьбы с ними повышение ЗП до некоего уровня, когда человеку будет хватать на всё.
Я рад, что вам нравится ваша сфера и вы готовы делать чуть больше в ней, чем требуется работой
У меня жена жаворонок и переманивает меня в свою секту, так что теперь я нахожу 20 минут перед работой.
Плюс этого в том, что тебя хватает на сложные
Также подкину идейку: статья про мерджи бд в гите для битрикса отлично бы зашла.
Ответственный за проект бэк [...] разбирался в кодовой базе vue, где большую часть писали не они двое (я как раз, кстати). [...] попал в ужасную ситуацию — работал до часу ночи всю неделю, сильно стрессовал, но и на него же по итогу свесились все шишки, в особенности из-за того, что он всё это время повторял “починю к обеду / к концу дня / к ночи / к утру”. [...] всё это вылилось в то, что пока мы решали его дальнейшую судьбу, он сам написал заявление об увольнении, так как устал такого стресса.Хочется надеяться, что фраза «решали дальнейшую судьбу» означает «решали, сколькократную премию ему дать за усердную и сверхурочную работу», а не «решали, не уволить ли чувака, который из кожи вон лез спасти всех от бага, который внёс не он».
Парень действительно был отличным: ответственный, позитивный, трудолюбивый, но тут личные качества не спасали, так как образование таких «чёрных дыр» у него было слишком частой практикой.
Звучали разные идеи. Самыми приятными и безобидными были идеи вроде «сидеть с ним вдвоём и вместе оценивать задачи, которые он собирается делать, потому как проблема возможно отчасти в оценке»
Выработал для себя пару правил, которые надеюсь могут помочь. Во-первых надо вовремя распознать, что человек закопался. Предложить пересмотреть сроки, подвинуть дедлайн. Во-вторых просто пропускать мимо ушей «починю через час» — это всё равно не правда, ясно ведь. Далее если не помогло — срочно передать всю задачу целиком другому. Это сложно, ведь этот может оказаться самым знающим, тогда хотя-бы подключить второе мнение. Лид или менеджер должен взять на себя всю ответственность за провал и перенести сроки. Больно и не хочется, но надо. И только после успешного релиза обсудить «что пошло не так и как сделать лучше в следующий раз». Но сначала признать, что человек таки сделал хорошую работу, в общем то.
А далее уже параллельно думать, нужен ли он в команде. Понимать, что с точки зрения морали команды, повесить всех собать и дать уволится — плохое решение.
Опять же, доводилось работать с людьми, у которых были проблемы с оценкой, с коммуникацией оценки, вообще с тем чтобы сказать «нет». В некоторых случаях (не всегда, конечно), лучше всего просто учитывать и подстраиваться самому.
Придя с галеры, в дикие прерии, он одолел дракона, показав как стучать на барабане.
На момент начала моей работы менеджер ставила задачи ужасно. Пример: название задачи — “Исправить баг на сайте” и всё: ни какого-либо описания, ни скринов, только название и отсылка к проекту. Были конечно попытки донести принципы SMART и важность описания задач до менеджера, но все начинания разбивались об “У меня нет времени расписывать задачи”.У нас похожая история.
Я тестировщик. Недавно я написал нашим тимлидам, что давайте введем критерии качества для тикетов и задач. Их элементарным качеством должна быть проверяемость. Т.е. если это баг- разработчик должен иметь возможность воспроизвести сценарий самым простым способом. (Я это называю «дай шанс разработчику пофиксить проблему») Если это задача, то она должна быть расписана так, чтобы третье лицо могло убедиться в том что она выполнена. Так же и разработчик, после обработки задачи, должен занести в тикет всю информацию необходимую для тестировщика или любого третьего лица, чтобы убедиться в том, что задача была действительно выполнена или проблема была исправлена.
Все отговорки — банальное проявление или попытка проявления халатности. А халатность в работе заводит в конце концов в Петлю Страха
Это не так трудно как кажется. Я когда пишу тикет, даю полный расклад, потому что хочу чтобы задачу быстро решили. А потом, проверяя исполнение, я не хочу мучительно вспоминать как воспроизводится эта проблема. А цикл от создания тикета до его решения бывает и пару месяцев, и тогда ты уже точно можешь не надятся на свою память. И это окупается. Редкие случаи когда разрабам приходится подходить и что-то переспрашивать. И даже в таких случаях все сводится к тому, что я открываю тикет в багтрекере и просто зачитываю из него с параллельной демонстрацией на продукте. Ну поленились прочитать. Бывает.
Когда я завожу технический баг, например на наш тестовый фреймворк, то прилагаю файл с тестом с помощью которого можно проявить проблему. Так же, если я хочу какую-то фичу в тестовом фреймворке, то к текстовому описанию с указанием моего намерения (зачем, для какого сценария мне это надо) прилагаю файл с тестом, в котором показано, как я хочу это использовать. Задача исполняющего — сделать так чтобы это заработало. Такие таски выполняются на удивление быстро и с минимумом доработок.
Короче: чем хуже описание — тем дольше будет обрабатываться. Причем не в масштабе «час-два» а в масштабе «день-неделя». Это связано с устройством работы мозга. Все что непонятно он с удовольствием откладывает на потом.
Я рад, что у нас уровень постановки сильно повысился. Но странно, что не все считают это критически важным даже с несколькими годами опыта.
Все что непонятно он с удовольствием откладывает на потом.
И это неправильно. Девелопер не имеет права отложить баг на потом. Зато может с поддержки техлида просто вернуть назад тестировщику с пометкой «непонятно». В клинических случаях когда название задачи «исправить баг на сайте» — ответ должен быть аналогично идиотским, вроде "исправил баг на сайте", либо "открыл сайт, он открылся. Значит бага нет.".
А потом ведь менеджер может и спросить, как это у нас в проекте 10 критических багов и все тестерам вернули.
ответ должен быть аналогично идиотским, вроде "исправил баг на сайте", либо "открыл сайт, он открылся. Значит бага нет.".
Я думаю, для дела будет лучше написать, "не удалось воспроизвести, недостаточно информации" и привести ссылку на принятые рекомендации по оформлению ошибок типа https://geteasyqa.com/qa/write-bug-report/, но адаптированную для вашего продукта.
Плюс чёткое описание задачи и разбиение на подзадачи помогает более адекватно оценивать время на её решение. При общем описании много нюансов можно просто не увидеть.
Мое мнение — это неправильная, конфликтная стратегия.
Перечить не надо. Надо уточнять. Идиотский ответ — это уже «перечить» (вы сами понимаете, что проблема есть, но тот, кто зарегистрировал ошибку не знает как о ней сообщить и не понимает, что данных недостаточно. Кстати, тут возникает вопрос, почему он не понимает. Может быть софт не подсказывает как это делать правильно? У него нет инструкции?)
Четкое описание задачи — это навык. Обычно он появляется от опыта. Надо помогать коллегам его приобретать. Обычно люди, которые могут решать проблемы в целом, стоят дороже чем люди которые копают отсюда и до обеда.
Дорогой программист (при прочих равных) должен иметь приветливый дуракоустойчивый интерфейс с проверкой на ошибки. Или будте готовы к распределению стоимости в пользу более дорогого консультанта, тилида или кого-то еще кто будет вас понимать.
вы сами понимаете, что проблема есть, но тот, кто зарегистрировал ошибку не знает как о ней сообщить и не понимает, что данных недостаточно.
«Не понимает» — это возможно, конечно надо уточнить, помочь, подсказать. Однако формулировка «исправить баг на сайте» — это скорее лень и неуважение к времени окружающих. Если один раз — ок, если повторяется — то человека нао заставить работать доступными методами.
В своем петпроекте в разделе форума "ошибки" я ввёл и описал подобные правила заведения багрепортов. Обычные юзеры, многие далёкие от разработки или тестирования стали ВСЕГДА писать нормальные описания ошибок. Я не представляю как люди за зарплату могут этого не делать. Похоже на саботаж, мне кажется.
Шаблоны это хорошо. Они наталкивают на идеи и экономят ментальные силы
Вот описание случайно выбранного бага на файрфокс
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) выглядит это примерно
A2:…
O2:…
A3:…
O3:…
E3:…
Кто-то пишет блок А потом блок O, и нужно сверять номера, но удобнее когда они чередуются «сделал-увидел-сделал-увидел-ожидал»
И такой нумерованый пошаговый подход тоже помогает, когда хочется написать роман или наоборот ничего не приходит в голову, он подталкивает «тупо» описать то, что наблюдаешь после этого действия, не вкладывая в это наблюдение никакой оценки. А потом, что ты ожидал получить, честно как есть. Может ожидание и не верно, но «в отделении» разберутся.
Плюс даже если баг воспроизводится только на одном компьютере- не факт что такие условия сложатся только у него. Вот из моего опыта за последние пару недель:
— У одного клиента не проходили запрос на сайт, так как в url содержалось слово advertise, и такие запросы резал Adblock. Без Adblock не воспроизводилось.
— У другого был заблокирован один и CDN, с которого сайт подтягивал скрипты
— у третьего в один момент роутер стал резать http-запросы, которые были длиннее X байт (такие клиенты по сайту ползали нормально, однако отправка больших форм не проходила).
А у меня сайт, я вообще к инфраструктуре клиента не имею никакого отношения.
Это же не значит, что такие задачи надо откладывать.
Особенно третий
Первые два ещё можно через удалённый доступ быстро распознать
На последней неделе был случай, когда нашёл странное место в коде, и смутно вспомнил что видел баг. Перепроверил, исправил, все довольны. Если бы бага не было — мог бы подумать что так и надо.
Срабатывает редко, но бывает. А вообще должен быть критерий, какие баги надо сразу править, а какие можно отложить пока не всплывут.
"У меня нет времени расписывать задачи"
А чем он[a] занимался?
Мы сразу говорим, что самое главное для нас это лишь уложиться в сроки решения задачи (называет сам исполнитель) и в конце показать рабочий код в репозитории.
Тут вы немного нарушаете роль оценки и планирования в Agile. И раз уж Вы решили внедрить Scrum — одну из Agile методологий, то разобраться с ее ролью придется. Видеоролик на эту тему от одного из 17 подписантов Agile манифеста https://youtu.be/eisuQefYw_o
Одной из самых больших проблем в компании было постоянное превышение сроков по задачам.
Если будет интересно, буквально вчера я изложил наш опыт как мы в разы увеличили темпы разработки.
Со стороны (для меня) это больше похоже на карго-культ. Вы приписываете особенности наблюдаемым факторам. Упуская из виду те, которые не наблюдаете.
Вот как это звучит:
«У нас был менеджер- лучше я на свете не встречал, так вот, он каждый день чистил зубы три раза, даже на работе, и отжимался по утрам.» А теперь о пользе зарядки и ежедневной гигиены...Это может быть большим заблуждением. Ведь причина может быть и не (только) в этом.
Когда человек работает сам по себе он всегда эффективнее человека работающего в команде. Ему не надо координировать свои действия, отчитываться, ходить на собрания, планирования — он сидит и фигачит. Пришла задача, сел делать, сделал, взялся за следующую. В принципе даже со стула можно не вставать.
Вот я, например, пишу тесты на четыре команды в общем 30+ разработчиков, и весьма эффективно. Просто потому, что я работаю сам по себе. Я эксперт в своей области. Проблемы в тестах или приложении я определяю как правило навскидку. Могу править тестовые скрипты вслепую (не запуская их на приложении для проверки), потому, что точно знаю как работает их код. Но за рамками моего «княжества» мои «супер способности» пропадают.
Если меня заставить делать еще и какую-то менеджерскую работу, обучать кого-то, делегировать, координировать, вся моя эффективность сразу сойдет на нет. И общая эффективность сойдет на нет. Потому что четыре новичка, которыми управляет сениор, никогда не провернут столько же, сколько сделает сениор сам, без чужой помощи.
И архитектура тестового кода у меня рассчитана на то, чтобы быстро писать новые тесты. Можно было бы там классовые структуры наворотить — пробовал — понял, что это меня только тормозит. Для себя вывел принцип: «Не корми кодом архитектуру, корми кодом приложение». В моем случае тесты. Вот и весь аджайл.
И общая эффективность сойдет на нет. Потому что четыре новичка, которыми управляет сениор, никогда не провернут столько же, сколько сделает сениор сам, без чужой помощи.
Это ловушка. Если работать таким составом, то сеньор будет погребён под грудом мелких задач, а новички так и не будут развиваться
Я, знаете ли, не до конца уверен, что его эффективность была всего лишь результатом применения «четырех принципов». Дело в том, что в истории нет абзаца «и вот мы внедрили эти четыре принципа в команде, и все стали работать так же быстро как он».
Хорошее замечание, спасибо, добавил пару строк.
На самом деле, темпы разработки выросли не только у тех, кто работал с ним, но и, по цепной реакции, у тех, кто работал уже с этими, и даже в других компаниях, и так на протяжении уже нескольких лет.
все начинания разбивались об “У меня нет времени расписывать задачи”
Автоматический reject на "задачи" подобного типа обычно решают ситуацию.
Т.е. конечно, сначала вежливая просьба, потом получение ЧСВ "я слишком занят/а чтобы...", а уже только потом reject, жалоба "обиженного" индивидуума, чьи "очень важные задачи проигнорированы", общение с начальством "обиженного", аргументация проблемы, после чего "обиженный" получает люлей ещё и от начальства и наконец-то исправляется.
Во-вторых, мы решили не устраивать экзамен на собеседовании, а давать очень объёмную задачу, приближенную к нашим повседневным… Задачу на самом деле может решить и джун за пару вечеров,...
ИМХО — плохая практика. Лично для себя принцип отказываться от вакансий, в которых предлагают задачи требующие более 3-4 часов, просто потому что уже несколько раз тратил на подобное несколько вечеров, а результат нулевой.
P.S. Кстати, наличие тестировщиков — тоже ощутимо влияет на результат. Не "тестирующих разработчиков", а профессиональных, системных тестировщиков. Чтобы минимизировать фейлы на 2-3 разрабов должен быть 1 "тестер".
2) К сожалению, собеседования это лотерея. Но мы не можем позволить себе брать миддлов и сеньоров без тестового.
2 — Да, лотерея, но надо заранее чётко понимать, что более менее состоявшиеся мидлы (а уж сениоры тем более) могут плюнуть на слишком долгую задачу и делают это в большинстве случаев. Есть много вариантов, как потратить время интереснее.
Никак, но надо понимать изменения психологии с ростом умений и навыков. Что, фактически, только джуниоры согласны на long-term задачи — они нарабатывают репутацию и опыт. Уже мидл скорее всего подумает: "А оно мне надо? 2-3 дня корячиться? Да ещё и забесплатно? Ну нафиг", но он хотя бы подумает какое-то время. Сениор же подумает: "Да блин, я уже всё всем доказал — ну их лесом с их задачами".
Вам надо как-то заставить захотеть решать эти задачи. Т.е. заставить желать эту работу даже сениору, но у них уже есть сложившееся мнение об индустрии и они требуют индивидуального подхода.
Но если человек и за деньги откажется, то наверное ему не нужна работа.
И ещё нужно учесть, что сеньоров на Битриксе днём с огнём не сыщешь. Люди в этой сфере наверное довольно быстро уходят на другие платформы
Ну тогда это даже не вопрос найма — если человек не заинтересован в принципе. Но тут опять же выходит мысль, сказанная ранее — к каждому сениору необходимо искать свой подход. Просто потому что там уже немного другие критерии подбора даже на "пойду или не пойду на собеседование".
В 95% случаях описание данной "рекламы" стандартно до тошноты, банальный пример — узнаёте?
Это настолько надоело сениорам, что проще и разумнее наверное в лоб говорить как то так:
- Есть стэк технологий: А, Б, Ц, Д и всё это вертится на Е
- Есть 4 человека на ПО: один — дятел, а ещё один периодически косячит, но с надеждой на исправление.
- В частях Б и Ц — трэш, угар и содомия — надо упорядочить.
- Код деплоим копи-пастом (что кстати было в том месте, где я работаю сейчас и введение git — законно считаю своим достижением =))
- Тестов нет. Никаких. Ни автоматических, ни хотя бы ручных.
- Менеджера два: один — гуманитарий, а второй вроде что-то шарит. Постить адекватные баги некому.
Надо разгрести — вот тебе зарплата 2000 евро сразу и каждый год поднимаем по 200 евро плюс премии. Чтобы получить премию надо родить ёжика против шерсти, но в целом мне два раза давали.
Как тогда без траты времени понять, что соискатель нам подходит, и соискателю подходят условия, компания и должность?
Vasek18, эта процедура давно отработана, прописана в ТК, и называется «испытательный срок».
И не надо со стороны работодателя ждать двух-трёх месяцев, чтобы сказать соискателю: «Извините, Вы нам не подходите». Три дня и — adieu.
То же справедливо и для кандидата.
Как вам такой подход?
Правда на позиции серьёзных специалистов я лично такого не припомню, но на позиции от джуниоров до мидлов бывало.
Просто я предложил ещё одну опцию. И, судя по другим комментам, я не одинок.
Если конечно не превратить этот испытательный срок в однодневную экскурсию. Человек и с командой познакомится и может быть таск реальный сделает, а на текущей работе просто выходной возьмёт.
Некоторые компании практикуют такой подход и хорошо о нём отзываются и он даже озвучивался в комментариях под этой статьёй.
Мне нравится этот принцип, сам я с таким встретился однажды лет 5 назад и до сих пор работаю на этом месте. То бишь меня опросили с чем я имел дело, опросили чего я жду от работы… И понеслась.
Этим кстати — решается ещё одна очень важная вещь — проверяется как человек вливается в коллектив. Просто он может писать прекрасный код, но на деле быть несколько неадекватным (для коллектива) и проверочный срок — решает эту проблему. А это, порой, важнее, чем красивый код. Потому что подучить коду или поменять привычные практики профессионал сможет, а вот психологически "не быть говном" — не факт.
Спрашиваю потому что приходилось увольнять человека с испытательного срока и было как-то совестно, что испортили ему трудовую.
По поводу задания, считаю, что добился очень не плохого результата, однако показалось немного грустным выполнение сложной профессиональной задачи за бесплатно, причём в Интернетах не найдёте особых туторов по рисованию 3D-текста. Если что, по условию задачи надо было именно разместить вершины в пространстве, шейдером или ещё чем-то. Это очень неприятный для меня опыт, который никому не пожелаю. Мысли были именно такие, как чуть ниже: «Да блин, я уже всё доказал, ну их лесом». Позвонил, сказал что не справился, после чего позвонил и сказал что согласен. Но уже другим ;) При этом довольно сложная область, это embedded systems со своей спецификой, к тому же увлекаюсь в матан, жаль data science за отсутствием опыта не найти. Думаю на битрексе конкуренция ещё жёстче, да и вы не гугл/яндекс. А так, такие задания это удел студентов (или вчерашних студентов), которым реально нечего делать.
P.S. У вас же есть какая-то статистика по отказам от тестового задания. Довольно интересно, какой процент отказывается от его выполнения? Потому что не первый раз отказываюсь и ничего не теряю, так как всегда были варианты без подобного бреда. И ещё, какие у вас зарплаты, если индивидуально — то какая вилка. И если не секрет, то ваш гонорар интересен ещё более, хотя по статье и имею представление.
Самым тяжёлым случаем у нас было, когда один соискатель на зп сеньора запросил 10 дней, а потом сдал слабенькую работу. Но тут проблема была в том, Битрикс не был его профилем, буквально 1 проект в портфолио и то считай вёрстка; он уже получал очень неплохие деньги на другом месте, как никак ему было под 40 лет уже. Мы бы не смогли предложить такой же уровень зп и для обоих это был бы проигрыш. Устное собеседовании всё подтвердило и мы могли бы максимум 40к предложить.
В целом я вас понимаю. При одинаковой зп, можно пойти и по пути меньшего сопротивления и выбрать компанию без тестового. И возможно действительно многие так и делают
Кстати, всегда терялся, что прислать, так как что-то тривиальное показывать не хочется, а сложный код в принципе не пишу.
В последние разы присылал домашние проекты, так как использую в них другие технологии и подходы, чтобы с ума не сойти от Битрикса. Но это тоже не очень правильно, так как не показывает мой уровень по основному направлени
Я на самом деле думаю набирать больше джунов, чтобы выращивать их.Лишь бы хотя бы сертификаты какие-то были сданы и знал бы как компоненты подключать. Но таких наверное только фуллстеков брать, так как чистый бек будет долго сидеть без задач иногда
Я конечно далек от тим лида, но как веб-разработчик, извлек для себя несколько полезных советов, которые помогут не наступить на грабли, если когда-нибудь попаду в команду.
Для первого подойдёт разговор с глазу на глаз типа «я с твоими пуллреквестами уже пальцы стёр, давай поговорим, буду голосом рассказывать» и расскажите человеку штук 5 (не больше) самых частых его ошибок… Подробно, чем это мешает, почему это не правильно, ссылки на статьи/стандарты, репродьюсер бага или сравнение по производительности/потреблению памяти… вообщем что угодно, чтобы он ещё неделю твёрдо помнил, что так делать не надо и подсознательно не хотел попасть на новую лекцию… ругать не надо, именно прочитайте лекцию…
А с другой стороны — не надо сразу на всё подряд внимание обращать — русскому/английскому языку вы точно человека не научите через PullRequest&Review, алгоритмы не вобьёте… а вот скобочки расставлять, лесенку делать или пользоваться несколькими библиотечными методами — можете, вот и ограничьтесь только 3-5 косяками (ну если нет чего-то совсем уж тушисвет), но отмечайте их с неотвратимостью автомата и заставляйте править — ошибки уйдут за месяц, а как только не станет этих — можно браться за другие.
Да, время жрёт кучу.
Скобочки/лесенки хорошо приживляются через code analysis. Вроде как и не лид зануда, а беспристрастная машина при поддержке авторитета сонм разработчиков, разработавших правила.
На самом деле пока проблем не возникало с форматированием кода. Но если ситуация будет ухудшаться, то я решу её через хуки гита и форматирование через php-cs-fixer. На прошлой работе так делал в качестве эксперимента. В результате все пишут как хотят, а перед коммитом код сам форматируется
Идея про внушения на созвонах довольно интересная, спасибо
“взяли миддлом/сеньором/старшим — стал миддлом/сеньором/старшим”. Когда я начал искать работу, мне бы хватило и позиции сеньора (и её я искал), но предложение тимлидства меня перекупило и немного польстило.
Процесс взятия лидом не раскрыт. Ведь далеко не всякий лид — сиьер, как и не любой синьер — лид
На эту позицию у меня было очень интересное собеседование. По сути это был двух часовой разговор в свободной форме про технологии, развитие фирм, команд, про работу по скраму, про Битрикс как про платформу и его альтернативы. Каких-то классических вопросов, типа, что такое позднее статическое связывание не было. Предложение мне сделали довольно быстро, но испытательный срок, конечно, был.
По сути сыграла просто моя готовность и желание быть лидом, так бы меня взяли старшим разработчиком, мб даже с сопоставимой ЗП.
Всегда казалось, что тимлиды появляются в структуре подчиненности тогда, когда появляются относительно независимые команды, с которыми начальник отдела (или департамента) разработки сам уже не успевает управляться.
Мне кажется, вся статья про то как человек с навыками сеньора поставил работу отдела разработки, фактически совмещая обязанности начальника отдела разработки и тимлида.
Это одна из причин, почему я писал статью. Должность тимлида довольно туманна и разнится от компании к компании, об этом ещё свидетельствует наличие одной большой конференции почти полностью посвящённой вопросу определения.
В нашей компании я тимлид, хотя по мало чего бы поменялось, если бы должность называлась старший разработчик или технический директор.
Я написал статью, чтобы тимлиды, техдиры, разработчики, hr, руководители, менеджеры увидели мои обязанности и это как-нибудь дополнило их представления. Плюс, чтобы кто-то в комментариях сказал: «это и это не обязанности тимлида, а вот это вот наоборот нужно добавить, да и вообще у нас так: ...». Поэтому мне было очень важно слово «Тимлид» в заголовке.
Если не трудно, проккоментируйте чуть подробнее вот это:
я ежедневно лично проверяю все оценки и постановку всех новых задач
Как много времени у вас это занимает? Возможно, я не правильно представляю кол-во задач у вашей команды, но на первый взгляд это воспринимается как «я пол дня сижу и проверяю задачи и так каждый день».
во все задачи закладываем время на тестирование, общение и сдачу клиенту
Вы как-то объясняете клиенту ценообразование работы целиком? Если да, то как вы аргументируете «надбавку» за общение и сдачу?
Спасибо!
Как много времени у вас это занимает?
До часа. Хотя я изначально боялся, что действительно по полдня буду сидеть. Но, во-первых, проекты редко меняются и кодовая база по большей части в голове, во-вторых, часть задач нужно просто посмотреть, что есть вся необходимая информация и здесь многое отсеивается, в-третьих, если за примерно 15 минут мы не сможем дать оценку, то мы создаём отдельную задачу под оценку, как, например, интеграция с очередной crm.
Вы как-то объясняете клиенту ценообразование работы целиком?
Ценообразование у нас очень сложное и абстрагирован от этого. Мы индивидуально подошли к каждому клиенту. Но мы и все наши текущие клиенты понимают, что работа над задачей это не только стукание по клаве, но и общение, выработка решения, обсуждение вариантов с клиентом,… Тем более, что с помощью общения мы часто ещё и удешевляем задачу, предлагая альтернативные подходы и подсказывая идеи.
Фишка же не просто время в деньги перевести, а улучшать клиентский бизнес.
1)Инструкции — дать задание, чтобы каждый программист выделял время на их создание до тех пор, пока важных для разработки вещей не будет в электронном виде
2)проблемы с гитом — какие могут быть проблемы? вы же наверняка видели, как и где они работают. Если кто-то не в IDE(а не дай б… в простом текстовом редакторе без автокомплита и поддержкой гита), то путь осваивают и учатся в том же шторме и там же использовать гит. Также не должно быть здоровенных коммитов и длинных задач, если это не исследовательские, используйте композицию
3)«но если твои коллеги саботируют регламенты, работают “по привычке” и не используют новые инструменты» — вы серьезно? перед такими работниками просто надо ставить выбор — либо работаешь с нами, либо досвидос. С вашей стороны, как лида, вы должны периодически общаться с подчиненными, тет-а-тет, особенно, если видите какие-то проблемы в работе. Никаких сюсюканий и детского сада, люди взрослые, ответственность должна быть у каждого!
4)«На два стула не сесть» — и не надо. У каждого есть должностные обязанности, на такие случаи кладется табу, он же болт на тех, кто пытается принудить сесть на эти оба стула
В общем и целом, то, что вы внедряется, вещи хорошие, приучать людей к хорошему надо, не взирая на их текущую зону комфорта(поскольку в итоге вы их пересаживаете в более комфортную зону), но делаете вы слишком мягко, неуверенно что ли… Удачи!
Я думаю, что как минимум отчасти вы правы по поводу мягкости. Сейчас мы вводим систему штрафов (не денежных) и она саботируется оштрафованными (было бы странно будь наоборот), и тут нужно уже как-то понажимать на коллег.
Проблемы с гитом были для меня вообще шоком. Мы даже экран иногда шарили, чтобы отловить проблемы.
У нас был один парень на Эклипсе и в какой-то момент пришёл сеньор(!) на нотпад++. Все остальные были в шторме, но как мне показалось, один иногда пытался работать через консоль, типа «олдскулл». Парень на Эклипсе правда ушёл уже какое-то время назад, но у него были другие проблемы.
Последней каплей было, когда я увидел пару логов в стиле «решал проблемы с мерджем» на полтора часа. Но тогда до меня уже дошла идея пятничных созвонов и буквально за 2-3 созвона мы пересадили всех в шторм и показали как решать конфликты. Сейчас по крайней мере уже пару месясцев не упоминаются проблемы с мерджами и потерей кода на созвонах, хотя кроме этого больше ничего и не было сделано.
Следующим шагом наверное будут пулл-реквесты
Про гит — с одной стороны пофиг, кто как работает, но есть устоявшиеся практики работы в IDE, которые облегчают и ускоряют мерж(для того они и написаны). «решал проблемы с мерджем» — после такого надо сразу подходить и давать выбор, либо пересаживаешься на IDE, вот тебе пару дней на освоение, либо на не по пути.
«пулл-реквесты» — а что вам мешало прийти и с первого(ну ладно, хотя бы через месяц) сказать типа: «Все, все работаем по типу гитхаба, используем гит флоу, пока кодревью я не закрою, задача в тест/прод не уходит». Соотв-но, все ваши замечания по кодревью будут устраняться, иначе задача будет превышать сроки. Демократия и равенство в коллективе хорошо, когда самостоятельность/проактивность и отвественность каждого не «на дне», а покамест вы начальник этого стада. Вот когда воспитаете подопечных, то можно будет и подкармливать «печеньками». Но только эти печеньки заранее озвучить, возможно для каждого свою, чтобы была прозрачность и мотивация.
Мы решили ввести какие-то наказания, потому что одни и те же люди, регулярно превышали свои же оценки или растягивали часовую задачу на весь день.
Мы сразу же обсудили, что не будем штрафовать деньгами, потому что как минимум пока не можем ими поощерять. В качестве штрафов мы решили ввести обязательные доклады/лекции, которые хотя бы косвенно относятся к причине превышения.
а что вам мешало прийти и с первого(ну ладно, хотя бы через месяц)
К сожалению, недостаток времени. Каждый программист писал код практически по 8 часов (минус созвоны), в том числе и я. И всё равно не успевали.
Сейчас вроде бы стало полегче. Думаю попробовать ввести практику совместных кодревью в конце дня.
Да и если быть честным, то на Битриксе трудно писать совсем уж плохой код.
потому что все деньги на премии уходили
И тут мы приходим к тому, что либо ваши сотрудники некомпетентны и не умеют планировать свое время(в этом случае возможно стоит пересмотреть материальное вознаграждение, а также делать декомпозиции задач, если они реально большие), либо сотрудник не понимает или не хочет понимать, что он приносит деньги, а не просто кодит и хабр читает(тут либо расставаться, либо проводить беседы)
в том числе и я
В смысле вы? Вы же устроились тимлидом, вот и тимлидьте, не лезьте на «второй стул». А так вы только распыляетесь, а картину видите только с опозданием, потому и времени на правильные решения уходит много
И тут мы приходим к тому, что либо ваши сотрудники некомпетентны и не умеют планировать свое время
Задачи всегда декомпозированы, конечно. Иначе они превращаются в эпик.
Считаю, что нет ничего более демотивирующего, чем денежные штрафы на работе или понижение ЗП. Поэтому решаем проблему развитием кадров и пробуем разные подходы для этого. Увольнять пока не приходилось и, слава богу, сейчас нет таких кандидатов
В смысле вы? Вы же устроились тимлидом, вот и тимлидьте, не лезьте на «второй стул».
Да, я упомянул этот момент в статье. Про два стула
Но в любом случае полностью переставать программировать я, наверное, не буду
сама разработка тоже была не ахти:
где-то что-то разрабатывалось даже вне гита
Скажите, как вы определили, что команде нужна децентрализованная система контроля версий, а не что-то иное с master репозиторием? Что-то кроме «ну все же используют гит, и это все знают»? Это связано с workflow именно этой команды?
Нужно просто не терять код… иметь актуальную кодовую базу, хранить устаревший код для справки, знать, кто что исправил и зачем,
выполняется и централизованными скв.
не перезаписывать чужие правки на проекте
Почему? Любая правка может быть перебита новой правкой. Как было до — для этого есть неизменяемая история.
работать изолировано
Часто приходится переключаться с задачи на задачу, бросая на полдороге?
хранить удалённую копию кода на случай выхода человека/компьютера из строя.
Опять же, это позволяет любая скв.
где-то что-то разрабатывалось даже вне гита
В данном случае не значит, что использовалась какая-то другая система. Тут говорится про проект, где был один сервак на всех и программисты по очереди правили файлы, подключаясь по фтп. То есть не было вообще никакой скв, программисты просто правили файлы в надежде, что сервак не будет крашится и всё.
Практически один в один как у нас в отделе разработки.
Мы также пытаемся внедрить scrum.
Как вы с разработчиками оцениваете время реализации задач в спринте?
Про неоплачиваемое тестовое задание… Мой опыт показывает, что есть смыл только для джунов. Мидл и выше по хорошему уже должен понимать ценность своего времени. Кандидату который рассматривает несколько компаний делать тестовое в каждую из них потребует уже не пару вечерочков. Кроме того, за пару вечеров можно написать примитивный код зачастую являющийся примером плохих практик и реальном проекте так бы человек писать не стал. Но своими пару вечерами вы заставляете его либо потратить много времени, либо написать плохой код. И что вам покажет результат такого тестового? Ничего. Ни по софт скилам, ни по техническому уровню. Тут в комментариях уже писали, что минут 20 личной беседы и уже понятно без всякого тестового задания.
Ну первым делом сначала идёт беседа. Это один из уровней фильтрации. Плюс вдруг соискатель расскажет что-то такое, что мы ему и тестовое не дадим, а сразу возьмём
Но в Битриксе нужно знать очень много специфических вещей, а код у Битриксоидов часто можно назвать «не очень», хотя это просто «стиль Битрикса», поэтому чаще всего решения пограничны
На собеседовании можно многое узнать о человеке, о его подходе к решению задач, знании языка и т.д. Но как человек кодит в реальной жизни понять сложно, краткие задачи типа сортировки массива этих знаний не дадут. Другое дело, что задание может быть не слишком большим: подробности можно дополнительно разобрать на втором собеседовании, и просто пройтись по тому, что ещё можно было бы сделать, а что можно было бы архитектурно изменить, если бы у испытуемого было больше времени.
Я один раз брал на работу человека, о котором после собеседования осталось впечатление «скорее не брать», однако в итоге с радостью взял, увидев его задание.
То что дефицитные специалисты могут отказаться делать тестовое задание — это не значит, что оно плохо для оценки способностей. Кстати, оплата за задание не факт что выход, разве что небольшая дополнительная мотивация.
Хочу прокомментировать один момент, с которым лично столкнулся много раз и вразных проектах:
Мы оооочень много думали над проблемой КПД. Явных протечек видно не было:
программисты оценивали задачи довольно здраво
реально над ними работали, а не просто ставили таймер
с коммуникациями не было никаких проблем
Но потом всегда что-то шло не так и каждый раз разное:
находился подводный камень
итоговое решение не устраивало клиента
отваливался какой-то смежный функционал
при тестировании что-то пропускали и потом переделывали
теряли время на поиск каких-то доступов
…
Раз явных протечек не было, то второй список почти не имеет смысла — это просто жизнь / неопределенность / законы Мерфи. Его можно составлять на предмет анализа повторяемости, но с ним поделать ничего нельзя — проблема старая, как трактаты Сунь-Цзы.
Если занимаетесь взаимосвязанными задачами (и, в идеале, используете ганта), а не чистым хаосом типа разгребания багов из helpdesk, то мне помогает прием из ТОС (это который Голдратт / Цель и т.п.). Суть в двух словах проста — пусть все дают самую минимальную оценку для своих задач в идеальных условиях (если не отвлекают, ничего не отваливается, все доступы есть и т.п.). Это важный момент и он придет не сразу (!) — надо донести и донести(!) мысль, что это не обязательство и вообще завершение задачи в эти сроки вы не ждете — на то они и идеальные. Более того, если человек в эти сроки регулярно укладывается, то он явно не отдал всю подстраховку и с ним надо серьезно побеседовать.
Эти оценки пишете в ганта, получаете идеальную / нереальную дату завершения. Дальше к ней в конец добавляете «буфер проекта» — рекомендую начать с равного 100% критического пути. Если получили очень поздний дедлайн — значит либо народ не сдал в общий котел личные подстраховки, либо вы ставите нереальные дедлайны )).
Перед всеми боковыми ветками по той же схеме добавляете «боковые буферы» и определяете промежуточные дедлайны для второстепенных задач. Теперь вся неопределенность и риски будут пожирать время из буферов, вам остается направлять все усилия только на те задачи, которые пожирают буфер быстрее, чем продвигаются. Т.е. задача на 4 дня, которая съела 3 дня из буфера — ok. Задача на 1 день, которая съела 2 из буфера — НЕ ok. Плюс в том, что уже на первой трети проекта усилия и внимание автоматом будут на самых проблемных местах и есть шанс закончить без ночных бдений.
Конечно, это не так хорошо работает в коротких спринтах, на длинных проектах эффект очевидней. Но если научите давать оценку времени без учета подстраховки — это здорово вам поможет при любых принципах управления.
При более детальном планировании (как раз на уровне спринта) мне больше нравится учитывать риски от девелоперов. Потому что на нашем проекте бывают тривиальные откатанные задачи, по ним можно смело брать идеальную оценку без подстраховки вообще, и вкладываемся. А бывает девелоперы видят возможные риски, и тогда надо добавить чуть больше.
Немного не понятно в чём выгода работы с минимальной оценкой и буфером в сравнении с работой с оценкой с рисками от самого программиста?
Например, если он просто всегда будет говорить 1 час?
И тут срабатывает студенческий синдром — если срок назван, то очень маловероятно, что задача будет закончена раньше — даже если риск не сработает, заложенные излишки времени уйдут в лучшем случае на полировку решения или еще какой-нибудь перфекционизм.
А так — все риски собраны в один большой риск (буфер) и стоят в нужном месте, защищая дэдлайн. И схожие риски не дублируются.
Работа тимлидом в 2018-ом году