Здравствуйте, landerhigh, Вы писали:
P>>1. вы пилите, условно, еще одну приложуху из того класса что пишут везде. Неопределенность минимальна и ограничена почти что исключительно заказчиком, то есть — архитектура, стек, основные проблемы известны еще до старта проекта. Проблем хватает, но про них почти всегда известно, что "ну, можно и обойти" или "вернемся позже"
L>Нет, не пишем. L>Зачем?
Затем, что деньги платят за готовый продукт который делает чтото полезное, а не просто код
P>>2. вы пилите приложение, навроде которого до вас никто еще не писал — здесь у вас риски вообще везде, не считая заказчика, P>>вы не знаете ни примерную архитектуру,
L>Знаем.
Если знаете, то это п1, который по вашим словам вы не пишете.
P>>ни проблемы,
L>Знаем/преполагаем/оцениваем.
см п1
P>>не можете оценить перформанс,
L>Можем. И оцениваем
см п1
P>>издержки на инфраструктуру итд.
L>Можем. И оцениваем.
см п1
P>>Во втором случае у вас по естественным причинам возникает траблшутинг/суппорт буквально каждый день. Например — вы запилили прототип сервера, ушло один день. Далее у вас цепочка непредсказуемых фейлов, и вам нужно это всё побороть.
L>Это уже какой-то клинический случай, если честно.
Это вы решили пометать понты когда про п1 написали "не пишем". А потом все свели именно к п1.
P>Необязательно. Траблшутинг, суппорт тоже сюда относятся.
... и в скрам это все рассматривается и поддерживается. Вы вообще когда-нибудь работали по скрам? Там действительно учитывается "available time". Плюс задачи оцениваются не в "неделях" или "днях", а в "story points", которые позволяют отделить "сложность" от "времени". Чтобы потом, по мере накопления статистики, вычислить эту самую velocity, суть отношение story points/time.
__>на самом деле цель системы — снизить порог входа, чтобы все люди были взаимозаменяемы и любой, условно, с дипломом, точно так же работал, как тот кто половину проекта сам написал за пять лет.
Это святой грааль менеджмента, "derisking".
Но вот чего менеджмент обычно не понимает, так это последствий такого "снижения порога". На самом деле происходит не снижение порога, а потеря эффективности работы опытных людей. Иными словами, не новички начинают работать быстро, а опытные вынуждены замедлиться (потому что "долго компилируется", "медленно идут тесты", "slow rollout", "напиши вот эти бумаги" и все такое прочее).
Иногда, впрочем, менеджмент это понимает, и честно говорит, "нам пофиг, что эффективность намного ниже, зато мы говорим, что разработка теперь предсказуема, без колебаний производительности, и рисков, что уход сильных инженеров приведет к существенному замедлению работ". И потом, разумеется, менеджмент добавляет "но нам нужно больше людей". Подразумевая "моя зарплата должна вырасти". Ведь все дело в этом, а вовсе не в рисках или чем-то еще.
P>Во втором случае у вас по естественным причинам возникает траблшутинг/суппорт буквально каждый день. Например — вы запилили прототип сервера, ушло один день. Далее у вас цепочка непредсказуемых фейлов, и вам нужно это всё побороть. Каждый фейл нужно рассматривать как новый, неизвестный ранее риск для которого нужно понять, как быть — игнорировать, или как то подстраховаться.
Такова разработка любого продукта, кроме совсем уж тривиальных.
Я в третий (и последний) раз повторяю: когда вы проходите этот процесс в десятый раз (на 11м спринте), у вас уже накоплено столько статистики, что вы В СРЕДНЕМ знакте, сколько этих фейлов произойдет, и как долго их исправляь. ПОДЧЕРКИВАЮ: В СРЕДНЕМ!!! Да, в каждый конкретный спринт вы можете выполнить "лишнюю" таску, а можете провалить спринт, не доделав ожидаемую (хотя в этом случае вам должны помочь другие члены команды, которые, В СРЕДНЕМ, уже освободились от их собственных задач на спринт).
P>Поскольку вы ничего про это не знали, ваш спринт накрылся медным тазом.
Да, накрылся! И первые 7-8 спринтов это будет происходить чуть менее чем всегда. Система начинает работать тогда, когда вы уже накопили статистику, и опыт в оценке задач. Я не знаю, сколько раз нужно еще это повторить, чтобы вы поняли.
P>В конце, если задачи решаемые, вы найдете примерную архитектуру приложения, только далеко не факт, что бюджета хватит на ваши изыскания.
Задача скрам — ограничить потери. Если в середине проекта стало ясно, что вы не уложитесь в бюджет (по времени или деньгам), можно либо свернуть проект, либо убрать фичи, либо добавить людей, либо исправить сроки. Суть процесса — в существовании этой накопленной статистики. Это точно работает, и потому столь нелюбимо многими любителями "покопаться годик в прикольных кишочках ресерч-проекта". Оно для бизнеса, а не для хобби.
Здравствуйте, SkyDance, Вы писали:
SD>Такова разработка любого продукта, кроме совсем уж тривиальных.
Нет не любого. Иногда люди пишут совсем нетривиальные вещи, и именно с этого чаще всего начинается бизнес. Да и невозможно всегда писать одно и тоже.
Я когда-то насмотрелся на одни и те же повторяющиеся действия: простенький Select, маппинг результатов на коллекцию объектов, отображение, редактирование. После сотого повторения я написал сначала простенький генератор таких селектов с генератором классов для маппинга результатов на коллекцию. А о том, что гуй можно автоматом генерировать я и раньше слышал — так ещё мой школьный товарищ делал.
Рано или поздно вот такая тупая работа автоматизируется и ты оказываешься не нужен.
Всё сказанное выше — личное мнение, если не указано обратное.
Да, на собеседовании уже было видно, что к ним идти не надо
S>>а затемо стал каждый день тупо готовиться к собеседованиям Аё>Чтобы в следующий раз наступить на те же грабли.
Здравствуйте, Артём, Вы писали:
CC>>C чего ты взял? Аё>Наблюдения.
Какие?
Аё>>> а проект нужно зафейлить? CC>>Надо принести себя на алтарь долбоклюйства менеджмента, да! Аё>HR- это не продакт менеджмент.
То, что он описывает это не про HR, это как раз про менеджмент.
Аё>стоит ли менять контору из-за политик отдела кадров.
Стоит.
Аё>В теории. А на практике кое-кто держится за Эппл.
Артёмка,
Наш внутренний менеджмент отлично понимает что на самом деле важно а что всего то для галочки.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, Antidote, Вы писали:
A>Да, на собеседовании уже было видно, что к ним идти не надо
Ох меня припекает на них. Они типа учат другие компании, как нужно бустить мораль- а сами провели 2 жёстких сокращения за 3 года.
S>>>а затемо стал каждый день тупо готовиться к собеседованиям Аё>>Чтобы в следующий раз наступить на те же грабли.
A>Грабли у всех разные
Сергей везде находит одинаковые
Здравствуйте, SkyDance, Вы писали:
SD>Такова разработка любого продукта, кроме совсем уж тривиальных. SD>Я в третий (и последний) раз повторяю: когда вы проходите этот процесс в десятый раз (на 11м спринте), у вас уже накоплено столько статистики, что вы В СРЕДНЕМ знакте, сколько этих фейлов произойдет, и как долго их исправляь. ПОДЧЕРКИВАЮ: В СРЕДНЕМ!!! Да, в каждый конкретный спринт вы можете выполнить "лишнюю" таску, а можете провалить спринт, не доделав ожидаемую (хотя в этом случае вам должны помочь другие члены команды, которые, В СРЕДНЕМ, уже освободились от их собственных задач на спринт).
Звучит как: "В каждом инженерном проекте раз в N недель случается K больших жоп и M жоп поменьше, на преодоление большой жопы тратится L человеко-часов, на преодоление средней жопы -- P человекочасов, на преодоление маленькой жопы -- Q."
Вне зависимости от типа проекта. Просто так случается и все. Так устроен мир.
А вопрос лишь в том, чтобы экспериментальным путем для своей команды выяснить значения N, K, M, L, P и Q.
Здравствуйте, CreatorCray, Вы писали:
CC>Какие?
Я наблюдал смену директоров кадровиков регулярную.
CC>То, что он описывает это не про HR, это как раз про менеджмент.
Это может быть уровень CEO. Наскучит CEO эта техника "повышения производительности"- найдёт другого массовика-затейника.
CC>Наш внутренний менеджмент отлично понимает что на самом деле важно а что всего то для галочки.
Это хорошо заметно по глюкам в яблочных продуктах. Нет если тебя устраивает по деньгам и технически работа нравится- я не призываю бросать.
Здравствуйте, SkyDance, Вы писали:
P>>Необязательно. Траблшутинг, суппорт тоже сюда относятся.
SD>... и в скрам это все рассматривается и поддерживается. Вы вообще когда-нибудь работали по скрам? Там действительно учитывается "available time". Плюс задачи оцениваются не в "неделях" или "днях", а в "story points", которые позволяют отделить "сложность" от "времени". Чтобы потом, по мере накопления статистики, вычислить эту самую velocity, суть отношение story points/time.
Вы наверное не в курсе, но скрам не применяют в операционной деятельности навроде траблшута или суппорта. Вам тупо нечего планировать, вне зависимости от попугаев
Почему ресёрч похож на опрационную деятельность — уже показал
Итого — у вас общие слова, и ничего про планировоание спринта у вас нет
Здравствуйте, SkyDance, Вы писали:
P>>Во втором случае у вас по естественным причинам возникает траблшутинг/суппорт буквально каждый день. Например — вы запилили прототип сервера, ушло один день. Далее у вас цепочка непредсказуемых фейлов, и вам нужно это всё побороть. Каждый фейл нужно рассматривать как новый, неизвестный ранее риск для которого нужно понять, как быть — игнорировать, или как то подстраховаться.
SD>Такова разработка любого продукта, кроме совсем уж тривиальных.
Еще раз — я говорю об исследованиях, а не продуктовых проектах. То есть — R&D, а не абы что вида "нагуглил либу и пример кода"
Вы мне талдычите как у вас хорошо было на продуктах. Можете себя не утруждать — это я и без вас знаю.
SD>Задача скрам — ограничить потери. Если в середине проекта
Тут есть некоторая путаница. В проектах может быть исследование. В исследовании какие то части могут быть вполне себе проектом. Из этого не следует, что исследование и проект это одно и то же.
Цель исследования — получить новое знание. Цель продуктового проекта — получить собственно сам продукт.
Отсюда ясно, что измеряемость результата в одном случае есть, в другом — нет. Сами догадатесь, где измерямости результата нет?
И планирование делается совершенно разными методами. В исследовании — процесс, операционная деятельность. Попытки планировать это проектными методами дают тупик.
Собственно в начале проекта у вас всё очень похоже на исследование, и именно поэтому скрам не работает. Вот дальше, когда неопределенность устранена, всё идет пучком.
Собственно хаос в начале проекта совсем необязательно будет — когда команда сработана, проект типовой, продукт овнер адекватный, вот этого хаоса у вас просто так не будет.
Здравствуйте, Артём, Вы писали:
CC>>То, что он описывает это не про HR, это как раз про менеджмент. Аё>Это может быть уровень CEO. Наскучит CEO эта техника "повышения производительности"- найдёт другого массовика-затейника.
мое субективное мнение, что уволили часть програаемров в США
практически выкеосили программеров и QA в Европе (продаж нет тк кризис у них, мне вот поручили сопровождать проект за немецкими программситами)
а все это с баллами придумали что бы стимулировать людей работать больше
Здравствуйте, Артём, Вы писали:
A>>Грабли у всех разные Аё>Сергей везде находит одинаковые
отчего же
у меня зарплата не как в FB но 98% вакансий в Бостоне отсеиваеться тк там меньше
последнии полтора года 90% пишу новый код и 10% баг фикс, обычно в США наборот
узнал много нового, изучил новомодныен технологии
P>Вы наверное не в курсе, но скрам не применяют в операционной деятельности навроде траблшута или суппорта. Вам тупо нечего планировать, вне зависимости от попугаев
Это вы не в курсе про планирование операционной деятельности. Там тоже все давно известно. Включая рекомендацию вместо скрама использовать канбан (который по сути есть квинтэссенция "операционной деятельности"). Лично мне не довелось долго работать с этой методикой, поэтому от комментариев я лучше воздержусь.
P>Еще раз — я говорю об исследованиях, а не продуктовых проектах. То есть — R&D, а не абы что вида "нагуглил либу и пример кода"
Сколько лет вы в индустрии, сколько уже видели разных проектов, как исследовательских, так и "продуктовых"? (отмечу, что "продуктовых" проектов не существует, если только речь не идет о типовых интернет-магазинах, которые здесь не обсуждаются).
P>Вы мне талдычите как у вас хорошо было на продуктах. Можете себя не утруждать — это я и без вас знаю.
Нет, я вам объясняю, что исследования тоже можно структурировать. И что по исследованиям тоже накоплена статистика. Каждый конкретный раз каждое конкретное исследование будет отличаться от предыдущих. Поэтому конкретный спринт будет отличаться от предыдущий.
Но на длинной дистанции все будет отлично видно.
P>Цель исследования — получить новое знание. P>Отсюда ясно, что измеряемость результата в одном случае есть, в другом — нет. Сами догадатесь, где измерямости результата нет?
Вот мы и дошли до сути разногласий: вы считает, что измерить результат исследований нельзя. Я считаю, что можно. Более того, если речь не о попиле бабла, первым, что должно оговариваться при старте очередной задачи/проекта/исследования — определение, что считать результатом, и как это измерить.
Скажем, "проверка гипотезы, что применение вот такой-то модели позволяет различить такой-то fraud от такого-то", — это очень даже результат.
P>И планирование делается совершенно разными методами. В исследовании — процесс, операционная деятельность. Попытки планировать это проектными методами дают тупик.
Вы это утверждаете, так и не попробовав. Я тоже так утверждал (до того, как попробовал). На осознание, что метод таки работает, у меня ушло некоторое время. Хоть я и скептически относился с самого начала.
P>Собственно в начале проекта у вас всё очень похоже на исследование, и именно поэтому скрам не работает. Вот дальше, когда неопределенность устранена, всё идет пучком.
Вообще-то, в середине проекта он был pivoted на совсем другие рельсы, так что неопределенность подпрыгнула до потолка. Собственно, и сам pivot случился потому, что стало ясно — с нынешней velocity мы ну никак не доберемся до feature complete к ожидаемой дате. Скрам вам не создаст определенность, его задача — примерно как у телеметрии (counters): записать реальную статистику, и на основе этой статистики прогнозировать.
Здравствуйте, sergey2b, Вы писали:
S>у меня зарплата не как в FB но 98% вакансий в Бостоне отсеиваеться тк там меньше S>последнии полтора года 90% пишу новый код и 10% баг фикс, обычно в США наборот S>узнал много нового, изучил новомодныен технологии
Тебе неугодить. Многие кто "абсолютно успешен на работе, не то что сергей2б", на самом деле 90% багфикс и они счастливы. А ты нет.
