ES
Если в компании два челвовека, стек холдер и разработчик?
-- Зачем мне тартить время на твое бубнение?
-- Зачем мне тартить время на твое бубнение?
Ну мы же не говорим про компании в два человека
Size: a a a
2020 September 15
АД
Ну мы же не говорим про компании в два человека
почему?
ЕЗ
Если в компании два челвовека, стек холдер и разработчик?
-- Зачем мне тартить время на твое бубнение?
-- Зачем мне тартить время на твое бубнение?
У тебя тогда непрерывный 1:1.
ЕЗ
1:1 нужен тогда, когда ты, как менеджер, не можешь держать руку на пульсе каждого члена команды без 1:1.
CM
Минимизируют время общения с клиентом, потому что у них обычно нет четких требований, зачем тратить время разработчика на выяснение, которое он мог бы использовать с большей пользой? Бывает, что у какой-либо из сторон есть недостаток софт скиллов, что не мешает им быть прекрасными работниками, но процесс затягивает намного сильнее. Прослойка в виде кого-то между разработчиком и клиентом гарантирует, что требования дойдут до разработчика более четкими (всё зависит от прослойки, конечно)
а что может быть полезнее, чем задача, которую он понимает?
ES
а что может быть полезнее, чем задача, которую он понимает?
А из подробного четкого описания в тикете он её не поймет?
CM
Неа, понимание это прям процесс
АД
1:1 нужен тогда, когда ты, как менеджер, не можешь держать руку на пульсе каждого члена команды без 1:1.
я не спорю с 1:1
я спорю с конкретным предложением
я спорю с конкретным предложением
ES
Неа, понимание это прям процесс
Так он в процессе чтения и будет её понимать
CM
Редко когда в тикете описывается мотивация, ссылки на исследование этой задачи и т.п.
CM
особенно если в команде два человека
АД
Так он в процессе чтения и будет её понимать
бывают случаи, когда за тикетом идет 3 полотна споров и два согласования тестов
ЕЗ
я не спорю с 1:1
я спорю с конкретным предложением
я спорю с конкретным предложением
А, сорян, потерял нить.
АД
Так он в процессе чтения и будет её понимать
был случай когда я так и не понял задачу, но сделал
ЕЗ
Минимизируют время общения с клиентом, потому что у них обычно нет четких требований, зачем тратить время разработчика на выяснение, которое он мог бы использовать с большей пользой? Бывает, что у какой-либо из сторон есть недостаток софт скиллов, что не мешает им быть прекрасными работниками, но процесс затягивает намного сильнее. Прослойка в виде кого-то между разработчиком и клиентом гарантирует, что требования дойдут до разработчика более четкими (всё зависит от прослойки, конечно)
А разработчик - это тот человек, что таски из TODO в DONE перекладывает?
АД
А разработчик - это тот человек, что таски из TODO в DONE перекладывает?
конечно, в хороших системах управления проектами есть кнопки InProgress и Done
CM
Так он в процессе чтения и будет её понимать
Тикет, пришедший разработчику — это просто артефакт уровня «Я думаю, что это нужно сделать»
Это ещё не значит, что тикет имеет смысл, возможен технически, или оптимален для ситуации
Это ещё не значит, что тикет имеет смысл, возможен технически, или оптимален для ситуации
ЕЗ
конечно, в хороших системах управления проектами есть кнопки InProgress и Done
Еще Blocked, конечно же.
f🤔
1:1 нужен тогда, когда ты, как менеджер, не можешь держать руку на пульсе каждого члена команды без 1:1.
даже в сверхмалых командах с минимальной иерархией, мне кажется, он всё равно нужен, как минимум с точки зрения ритуального повторения и, как следствие, возможности для обоих сторон интернализировать происходящие события
иначе остается риск, что что-то будет упущено за непрерывной текучкой
иначе остается риск, что что-то будет упущено за непрерывной текучкой
АД
Тикет, пришедший разработчику — это просто артефакт уровня «Я думаю, что это нужно сделать»
Это ещё не значит, что тикет имеет смысл, возможен технически, или оптимален для ситуации
Это ещё не значит, что тикет имеет смысл, возможен технически, или оптимален для ситуации
Два чая, я совсем забыл, потому что сбился со счета, сколько было тасок которые вообще не надо было делать