On 14.08.2013 14:44, Nuseraro wrote:

> В смысле? Если есть опыт, то не в 3, а ну +-30% где-то. И то за счет
> того, что лучше понял, как выглядит задача. Или ты про что?
Если у меня есть опыт, то вырастет во столько раз, во сколько нужно.
Единственный разумный подход применения такой детализации при
планировании на 2-3 недели вперед, чтобы было ясно, что разраб четко
понимает свои задачи, и не далее.

Здравствуйте, Vzhyk, Вы писали:

V>Если у меня есть опыт, то вырастет во столько раз, во сколько нужно.
Согласен, что это может получиться, если не контролировать время на нижнем уровне. Но обычно в слишком больших оценках получается "Нарисовать кнопку 'Сохранить' — 4 часа". При том, что есть "Функционал кнопки сохранения — 6 часов". А в слишком оптимистичных — "Форма заказа — 16 часов". Спрашиваешь "А что на форме?", "5 кнопок, 12 текстбоксов, проверка валидности заполнения текстбоксов". И всё понятно. А вы пробовали так поступать? С какими сложностями столкнулись?

On 14.08.2013 15:08, Nuseraro wrote:

> И всё понятно. А вы
> пробовали так поступать? С какими сложностями столкнулись?
С Гуями не сталкивался уже много-много лет и толком ничего не скажу. А в
других задачах детализацию в 2-3 дня требовал только на ближайшие 2-3
недели (чтобы убедится, что разраб понимает задачу и знает как ее
решать). Для дальнейшего детализация неделями или месяцами. При таком
подходе можно оперативно реагировать на задержки или ускорения у разрабов.
А вышестоящему начальству нарисуешь любую фигню, главное, чтобы в
ожидаемый срок укладывалась — все одно или они про эту бумажку забудут
или приоритеты 100 раз поменяют.

Здравствуйте, Nuseraro, Вы писали:

N>Мне кажется, что как и весь менеджмент, решение этих кейсов — ситуативно

В данном случае это скорее завязка для разговора.

N>Ключевые направления:
N>Сбор информации
N>1) Разобраться, почему непрофессионализм друг друга огорчает их — возможно есть, например, неправильно выстроенная система вознаграждения. Или просто люди разной культуры

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

N>2) Провести анонимный опрос всех членов команды про других членов команды в формате (Я считаю что этот чел — профессионал(-5 до +5), готов помочь (-5 до +5), ответственный (-5 до +5), командный игрок (-5 до +5), он мне не просто коллега, но и друг(+5 до -5)) Конечно будет и невалидность, но многое станет понятно

Идея организовать канал для обратной связи отличная, но сами вопросы ничего не дадут. Ты выяснишь что с точки зрения произвольного программиста те тестировщики с которыми он работал — ламеры, а те с которыми он близко не сталкивался тоже ламеры но получше. Аналогично в обратную сторону. С поправкой на личное отношение.

N>Тушение глобального пожара
N>3) Выделить парочку людей, которые проверяли бы баги на бизнес-ценность, не передавать баг разработчикам до "фильтрации"

Этим и так занимаются тимлид и пм. Или предлагается проверять каждый переход от тестирования в разработку и обратно?

N>4) Задать критерии качества для разработчиков — например, что описанный тестировщиками кейс должен проходить на некоторой сторонней машине, помочь им в реализации такого подхода вначале

Отлично.

N>5) Выявить зачинщиков(часто бывают в такой ситуации), переговорить с ними

Как именно переговорить и о чем?

N>Решение частного случая
N>6) По "вчерашнему случаю" — не понятно, какая культура у моей текущей компании. Если говорить про реальные компании, где я работаю — то просто поговорить с тестером, без относительно повода, о причинах увольнения. Попросить подумать, напомнить плюсы и минусы работы в компании, рассказать, что планирую работать с текущей ситуацией. Хотя при некоторых культурах тупо увольняем вед. разработчика ибо нефиг.

Поговорить это всегда правильно, но либо тебе придется рассказать что конкретно ты собираешься сделать с этой проблемой либо человек воспримет это как очередное бла-бла-бла.

Общая стратегия првильная, конкретные действия не очень понятны.

N>1) Ключевой подход для точных оценок — дробить задачу на мелкие, до 4-16 человекочасов. И по максимуму пытаемся всё учитывать. Возможно привлекая других людей, проверяя их оценки навскидку, типа "а это ты учел", "а это ты во сколько оценил? да че, правда?"

1 ч/год это где-то 2100 ч/часов, при твоей гранулярности это 150-500 задачь. Предварительное проектирование позволяющее добиться такой детализации занимает где-то от 10% до 30% времени от разработки, итого ты потратишь несколько месяцев только на полцчение оценки. Неприемлимо.

N>2) Разпаралеллить с внедрением фич — переписываем потихоньку те модули и части, которые в этот момент меньше всего(или вообще не) разрабатываются.

Разумно.
N>За счет средства контроля версий ведем в отдельной бренче. Часто мерджимся.

В этом месте поподробнее, что именно мы ведем в отдельном бранче, что куда часто мердджим и от каких проблем это нас спасает?

N>В зависимости от ситуации или пускаем на прод с частично на 1 орме, частично на другом, или в один замечательный день выдаем всё на новом ОРМе.

Если ты при это думал про ситуативный план, то просто превосходно.

N> Также надо, чтобы каждый разраб поучаствовал в разработке под новый ОРМ, чтобы не было резкого перехода.

Правильное замечание

N>Тут к счастью спасает, что быстро команду не утроишь

Зависит от толщины кошелька. В худшем для тебя варианте руководство просто купит команду на рынке. В лучшем ты можешь надеяться на 3 человек в месяц.

N>1) Каждому новому выделяется явно наставник из расчета 2 человека на наставника(возможно другая пропорция, если у вас в команде есть совсем интроверты или очень разный опыт)
N>2) Новички садятся максимально в перемешку со старичками но непременно рядом с наставниками и коллегами-новичками по наставнику.
N>3) Заранее подготовить некоторые образовательные материалы(базу знания, описания и и.д.).

Отлично.

N>3.1) Требовать от новичков разрабатывать образовательные материалы, а старичков ревизовать их.

Вместе с пунктом 1 это приведет к резкому падению производительности старичков. И потом, что ты называешь образовательными материалами и как именно они должны помочь?

N>3.2) Подготовить контроль знаний — ставить задачи новичкам на обучение с конкретными результатами

Отлично.

N>4) Оценить кривую обучаемости новичка — не планировать на новичков столько же работы, сколько раньше на 1 старичку тут же, но увеличивать требуемую нагрузку по мере стажа в компании (в принципе после 1 месяца должны быть полезны, за 3 месяца должны незначительно отставать от старичков(при равных общих скиллах), а через 9 влиться окончательно)

Как это поможет введению новичков в проект?

N>5) Набирать новичков с некоторым запасом, не бояться фильтровать после испытательного срока, да и сами могут уходить от некоторого неминуемого хаоса

Это уже за рамками кейза, но логично.

N>1) Обсудить с разрабами

Что именно обсудить и каким образом?

N>2) Рассмотреть тройку конкретных случаев, тщательно изучить через то же средство контроля версий(тут кстати помогут комменты к коммитам которые редко пищутся во многих компаниях )

Какие выводы мы сделаем из этого рассмотрения?

N>1) Объяснить начальству, что это вещь вероятностная

Т.е. ты пойдешь к CEO и скажешь: "дорогой друг, то что компания потеряла 10M это вещь вероятностная, как в казино", так что ли?

N>2) Обсудить с начальством какие механизмы/процессы/подходы могли бы помочь уменьшению такой вероятности, обсудить их стоимость и размеры вероятности
N>2.1) В том числе, на основании этого выработать приемлемые критерии кол-ва фейлов типа "доступность 99.99%"

Хорошо.

N>3) Если будут настаивать на виновном:
N>3.1) Если причиной является нарушение !явных! служебных инструкций кем-либо — назвать, заметив, что это человеческий фактор, на его месте мог бы быть каждый.

Где вы видели служебные инструкции запрещающие делать баги

N>3.2) Если ничего такого явного нет — то честно назвать себя

С целью произвести впечатление?

N>Ну собственно если собственно кода рабочего нет, разработчиков способных разрабатывать нет, какие-то обязательства при этом есть. Короче почти что случай чистого листа.

Бедная какая-то фантазия Многие наоборот мечтают начать новй проект с чистого листа.

N>1) Провести анализ ситуацию
N>2) Составить временной план решения текущих проблем
N>3) Согласовать план со всеми заинтересованными лицами
N>4) Реализовывать план

Q: Как засунуть жирафа в холодильник?
A: Открыть холодильник, засунуть туда жирафа, закрыть холодильник.

Здравствуйте, Vzhyk, Вы писали:

V>On 14.08.2013 15:08, Nuseraro wrote:

V>С Гуями не сталкивался уже много-много лет и толком ничего не скажу. А в
V>других задачах детализацию в 2-3 дня требовал только на ближайшие 2-3
V>недели (чтобы убедится, что разраб понимает задачу и знает как ее
V>решать).
V>
V>все одно или они про эту бумажку забудут
V>или приоритеты 100 раз поменяют.
Я так понял, что мы просто в разных условиях работаем, у вас что-то довольно гибкое и, как мне показалось, без явного фиксированного долгосрочного бюджетирования.
Я же тут преследовал цель — попробовать максимально точно оценить длительную работу для себя, несмотря на все возможные неопределенности. Не факт, что я эту же цифру всем озвучил бы, был бы я на вашем месте
И тут мне помогает подход нарезания на мелкие задачи — начинаешь лучше понимать какие составные части у задачи, на что пойдет основное время и т.д. Заодно имею некоторый первичный план работ. Занимает не очень долго, а польза в итоге ощутимая.

V>А вышестоящему начальству нарисуешь любую фигню, главное, чтобы в
V>ожидаемый срок укладывалась
Это понятно
http://www.rsdn.ru/forum/job/3952670

Автор: olegkr
Дата: 09.09.10

On 14.08.2013 15:31, Nuseraro wrote:

> Я так понял, что мы просто в разных условиях работаем, у вас что-то
> довольно гибкое и, как мне показалось, без явного фиксированного
> долгосрочного бюджетирования.
Нет, это был вполне себе большой и сложный госзаказ (срок и бюджет
жесткие, можно было бы даже похвастаться, что это было, но не хочу
лишнего светиться), который был сделан в сроки качественно, причем 90%
было R&D. Просто для начальства рисовались сказки несколько раз, чтобы
отстало и удовлетворилось. Реально-то их интересует текущее состояние
проекта в варианте покажи, как работает и вложимся-ли в срок. Но в силу
своих страхов и предрассудков страдают фигней обычно — нарисуй мне
красивые картинки.

> И тут мне помогает подход нарезания на мелкие задачи — начинаешь лучше
> понимать какие составные части у задачи, на что пойдет основное время и
> т.д. Заодно имею некоторый первичный план работ. Занимает не очень
> долго, а польза в итоге ощутимая.
Конечно, но нельзя увлекаться и планировать дальше 2-3 недель. Много
может поменяться, приоритеты, не угадать со сложностью задач, многие
задачи могут вообще отпасть и появиться другие и т.д.

З.Ы. Фактически это было что-то типо новомодных агиле, но никого не
ставя в известность и не использую подобных слов.

__>>Вот задам вопросы и узнаю.
0>А если соискатель даст правильный ответ, но не совпавший с тем, что тут сказали?

В таком случае, найму его на работу

N>2) Провести анонимный опрос всех членов команды про других членов команды в формате (Я считаю что этот чел — профессионал(-5 до +5), готов помочь (-5 до +5), ответственный (-5 до +5), командный игрок (-5 до +5), он мне не просто коллега, но и друг(+5 до -5)) Конечно будет и невалидность, но многое станет понятно

Немного оффтоп, но довольно важный: анонимность опросов в небольших (до ~30-50 человек) командах есть фикция. Все, в том числе члены команды, это прекрасно понимают.

Здравствуйте, maks__, Вы писали:

__>>>Вот задам вопросы и узнаю.
0>>А если соискатель даст правильный ответ, но не совпавший с тем, что тут сказали?
__>В таком случае, найму его на работу
А как ты узнаешь, что ответ правильный?

Здравствуйте, smallpoxlet, Вы писали:

N>>1) Разобраться, почему непрофессионализм друг друга огорчает их — возможно есть, например, неправильно выстроенная система вознаграждения. Или просто люди разной культуры
S>Вообще-то людей всегда раздражает чужая некомпетентность. В определенных условиях они могут скрывать это раздражение, но оно никуда не девается. В данном же случае совершенно необязательно речь идет о реальной некомпетентности.
Сама по себе? Довольно редко. Как правило раздражает она потому, что тебе приходится делать больше работы,или делать больше такой работы, которую ты не любишь, или дольше объяснять, или просто тяжелее общаться, или и вовсе бонус твой зависит.
И все это на фоне того, что команды имеют тенденцию к тому, чтобы иметь сходный профессиональный уровень всех членов. Короче с эти надо работать: объяснять всем что и они не ангелы, фокусировать ответственность людей на то, на что они могут повлиять: "Ты баги максимально честно и быстро исправляй, и будешь вознагражден, а если в итоге продукт плохой выйдет — смело вини нас, начальство — это мы недосмотрели"

N>>2) Провести анонимный опрос всех членов команды про других членов команды в формате (Я считаю что этот чел — профессионал(-5 до +5), готов помочь (-5 до +5), ответственный (-5 до +5), командный игрок (-5 до +5), он мне не просто коллега, но и друг(+5 до -5)) Конечно будет и невалидность, но многое станет понятно
S>Идея организовать канал для обратной связи отличная, но сами вопросы ничего не дадут. Ты выяснишь что с точки зрения произвольного программиста те тестировщики с которыми он работал — ламеры, а те с которыми он близко не сталкивался тоже ламеры но получше. Аналогично в обратную сторону. С поправкой на личное отношение.
Так действительно может получиться, но как правило картина гораздо интереснее. Может очень многое что оказаться
1) Что реальная ссора между 2 разрабами и 1 тестером, а все остальное — эхо этого
2) Что есть особо уживчивые тестеры и разрабы — возможно, их ставить в пример, поддерживать их позицию
3) Можно вычислить неформального лидера, который и плодит ненависть. Вспомним, что ссору начал ВЕДУЩИЙ разработчик. Кстати такие ребята часто бывают непрофессионалами или профессионалами, но с точки зрения знаний технологий, а те же баги правят плохо. Тут надо подумать, или совсем избавляться или переформулировать обязанности, чтобы только с девелоперами общался
4) Малое число людей образует команду, т.е. общие проблемы взаимодействия в команде. Все раздражены, все бесят всех, а уж "другие" и вовсе ненавистны. Тогда надо начинать процесс командообразования с нуля
Короче это надо.

N>>3) Выделить парочку людей, которые проверяли бы баги на бизнес-ценность, не передавать баг разработчикам до "фильтрации"
S>Этим и так занимаются тимлид и пм. Или предлагается проверять каждый переход от тестирования в разработку и обратно?
Идея в том, что по словам разработчиков им попадает фигня, а не баги. Надо поработать с этим, посмотреть — это действительно фигня или просто разрабы так думают? Если действительно фигня — сказать тестерам, чтобы не докапывались до мышей или по крайней мере осознавали этому, выставляя низкий приоритет таким багам. Если на самом деле это полезные баги — объяснять разрабам, что увы, правильный текст сообщения важен клиенту и он платит именно за него.

N>>5) Выявить зачинщиков(часто бывают в такой ситуации), переговорить с ними
S>Как именно переговорить и о чем?
Зависит от этапа сбора информации. Тут ключевая ситуация, что хотя часто менеджеру кажется что "все поступают так-то", например, "все сказали, что уволятся если не повысят зарплату"(кстати тоже кейс), выясняется что реально у этого всего есть организаторы и последователи.

S>1 ч/год это где-то 2100 ч/часов, при твоей гранулярности это 150-500 задачь. Предварительное проектирование позволяющее добиться такой детализации занимает где-то от 10% до 30% времени от разработки, итого ты потратишь несколько месяцев только на полцчение оценки. Неприемлимо.
Детализация сводится примерно к тому, чтобы записать например 150 классов/мест где вообще надо менять, сгруппированные по модулям с оценкой. У меня это занимает 1, ну 2 дня.

N>>За счет средства контроля версий ведем в отдельной бренче. Часто мерджимся.
S>В этом месте поподробнее, что именно мы ведем в отдельном бранче, что куда часто мердджим и от каких проблем это нас спасает?
Разработку переведенного на новый ОРМ функционала. Мерджим из главной ветки туда. Дает передельщикам на новый ОРМ спокойно жить, не задумываясь о проде.

N>>3.1) Требовать от новичков разрабатывать образовательные материалы, а старичков ревизовать их.
S>Вместе с пунктом 1 это приведет к резкому падению производительности старичков. И потом, что ты называешь образовательными материалами и как именно они должны помочь?
Зависит от проекта. Например, вписанные комменты в код. Или явная база знаний типа, мы используем наш внутренний самописный ORM, им пользоваться так-то.
Это делается например так: у новичка есть таск, наставник ему говорит, так, тебе придется столкнуть с нашим локализационным движком, нашим ормом и применить логирование через нашу библиотеку. Пользоваться ими так-то. Сделай порученный тебе таск, а потом напиши об этом, пожалуйста, статью/комменты в использованном классе, чтобы потом другие прочли, а если что, то к тебе подошли, спросили. Также можно например письмо послать другим новичкам, типа — я уже в курсе про то-то и то-то подходите если что ко мне, не отвлекайте стариков. Можно вести пошаренную информацию, кто какой модуль знает и насколько глубоко. Как правило при 10М и старики не все знают.

N>>4) Оценить кривую обучаемости новичка — не планировать на новичков столько же работы, сколько раньше на 1 старичку тут же, но увеличивать требуемую нагрузку по мере стажа в компании (в принципе после 1 месяца должны быть полезны, за 3 месяца должны незначительно отставать от старичков(при равных общих скиллах), а через 9 влиться окончательно)
S>Как это поможет введению новичков в проект?
Имеется в виду, что не оказывать давление по результативности в смысле прямой результативности поначалу. Поначалу результативностью считать главным образом, насколько человек все освоил и может юзать. Т.е. например, пришел человек, знающий какое-нибудь XSLT хорошо. Есть соблазн просто ему давать только все задачи, связанные с XSLT и будет хорошая производительность у него. Это часто неправильно, потому что задачи про XSLT заканчиваются, а человек глубоко не в теме.

N>>1) Обсудить с разрабами
S>Что именно обсудить и каким образом?
N>>2) Рассмотреть тройку конкретных случаев, тщательно изучить через то же средство контроля версий(тут кстати помогут комменты к коммитам которые редко пищутся во многих компаниях )
S>Какие выводы мы сделаем из этого рассмотрения?
Какие окажутся данные, такие и выводы
Например:
1) В коде мясо, вообще нереально править что-то. Тогда нужно учитывать рефакторинг и контроль архитектуры при каждом баге.
2) Код хороший, и у многих разрабов все хорошо, но конкретные люди очень неаккуратны — например, некорректно правят базовые классы для решения частных проблем. Тогда, провести работу с неаккуратными
3) Ошибки связаны не с программным кодом, а например, с изменением хардварной конфигурации/версии браузера/постоянно истекают какие-то права и что угодно. Тогда, работать с этим


N>>1) Объяснить начальству, что это вещь вероятностная
S>Т.е. ты пойдешь к CEO и скажешь: "дорогой друг, то что компания потеряла 10M это вещь вероятностная, как в казино", так что ли?
Если речь будет идти действительно о 10М, то я уж напрягусь составить четкий доклад и объяснение и продумаю по полной. Тем не менее по сути — именно так, потому что оно так и есть, и оно так всюду. Кризисы неизбежны.

N>>3) Если будут настаивать на виновном:
N>>3.1) Если причиной является нарушение !явных! служебных инструкций кем-либо — назвать, заметив, что это человеческий фактор, на его месте мог бы быть каждый.
S>Где вы видели служебные инструкции запрещающие делать баги
Таких не видел, но часто такого рода косяки, потому что кто-то мог установить что-либо несогласовав как должен. Людей задалбывает бюрократия и они делаются смелей, забывая, что бизнес может дорого расплатиться за это. Какая-нибудь прямое действие на проде — рестарт чего-то, изменение какого-нибудь конфига. Такие вещи в компаниях способных потерять 10М$ должны быть строго регламентированы. Тем не менее люди могут нарушать эти регламенты и в этом случае это их косяк, хотя нужно ли их после этого расстреливать? Удастся ли найти лучшего?

N>>3.2) Если ничего такого явного нет — то честно назвать себя
S>С целью произвести впечатление?
Нет, потому что видимо это я в этом случае — человек, который был обязан организовать наличие инструкций и регламентов, которые бы спасли компанию от потери 10М. Значит я не прав. К чему скрывать?
Если это не я — назвать того человека.

N>>Ну собственно если собственно кода рабочего нет, разработчиков способных разрабатывать нет, какие-то обязательства при этом есть. Короче почти что случай чистого листа.
S>Бедная какая-то фантазия Многие наоборот мечтают начать новй проект с чистого листа.
Ну обязательства при этом могут быть — сдать программу через месяц, код как бы быть, но реально не работать. Разработчики как бы быть, но ничего не уметь.

N>>1) Провести анализ ситуацию
N>>2) Составить временной план решения текущих проблем
N>>3) Согласовать план со всеми заинтересованными лицами
N>>4) Реализовывать план
S>Q: Как засунуть жирафа в холодильник?
S>A: Открыть холодильник, засунуть туда жирафа, закрыть холодильник.
Дык и ситуация пока абстрактная Например
Выяснить, что можно донабрать толковую команду за 3 месяца за такие-то деньги. За месяц — за другие.
Потом работы на год. Потом ещё всякой ерунды стабилизационной на год. Прийти с этим к стейкхолдерам.
Сказать так мол и так. Через месяц хочу всей душой. Но не могу. Могу через 2 года. Ну они сначала "Мы думали ты про" и всё такое, а потом спросят "А что можно через месяц, нам очень надо?"
Прикинем, может в имеющемся коде и есть что-то рабочее, например сказать что, будем эту часть багоправить и презентовать инвесторам, а параллельно разрабатывать всё заново.
Ну а потом 2 года работы с постоянным общением с менеджментом, чтобы успокоить их, что уж через 2 года-то всё будет, а пока выдавать какие-то альфы/бетты/материалы для продаж/демонстрации.
Правда зачем оно мне нужно?

Здравствуйте, SkyDance, Вы писали:

N>>2) Провести анонимный опрос всех членов команды про других членов команды в формате (Я считаю что этот чел — профессионал(-5 до +5), готов помочь (-5 до +5), ответственный (-5 до +5), командный игрок (-5 до +5), он мне не просто коллега, но и друг(+5 до -5)) Конечно будет и невалидность, но многое станет понятно

SD>Немного оффтоп, но довольно важный: анонимность опросов в небольших (до ~30-50 человек) командах есть фикция. Все, в том числе члены команды, это прекрасно понимают.

В случае явного написания развёрнутых ответов — да, это так. В случае заполнения простой таблицы с числовыми оценками — нет, даже в случае 3 человек часто уже путаешься, кто же выставил оценку. Особенно если убраны данные про связь ответов на разные вопросы.

Здравствуйте, smallpoxlet, Вы писали:

N>>3.1) Требовать от новичков разрабатывать образовательные материалы, а старичков ревизовать их.
S>Вместе с пунктом 1 это приведет к резкому падению производительности старичков.

Какое-то падение, конечно, будет. Но почему именно "резкое"?

S> И потом, что ты называешь образовательными материалами и как именно они должны помочь?

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