Комментарии 118
Почитал, помечтал, всплакнул и пошел на полуторачасовой ежедневный брифинг.
Если программисты перестают париться насчет сроков, и просто решают задачи, одну за другой, ни на что не отвлекаясь, то продуктивность возрастает вдвое.
это голословный комментарий или автор готов прийти в коллектив разработчиков и за деньги сделать x2 продуктивности?
Сосредоточенность + комфорт + спокойная атмосфера это 2^3.
Потоковое состояние очень недооцененная вещь в профессиях, одновременно
творческих и мастерских
Некоторые задачи требуют неспешности и аккуратности
Вот именно — а когда программиста постоянно дёргают…
Тут картинка Дорофеева про горшки и говно.
Раньше он даже x4 делал, но, судя по теперешним статьям, не очень-то спросом пользовалось. Перешёл на x2.
Попробовал так как-то. Программисты сделали не то и слишком поздно. Лучше контекст им все-таки давать)
Я конечно не против, чтобы в стартапах или маленьких коллективах был колелктивный архитектор и управляющий в виде совещаний, просто потому, что людей мало и всем нужно выполнять несколько ролей. Но в больших компаниях, которые могут себе позволить отдельных архитекторов, менеджеров, и другой выделенный специализированный персонал, стоит всё-таки принимать решения между специалистами в области этих решений. И чтобы менеджер не лез кодировать, например. Разумеется, обратная связь должна быть и в больших компаниях, но не в виде совещаний со всем коллективом — пусть все занимаются своим делом.
Любит программировать, но не любит получать задачи где остаётся только чужое решение закодировать.
А в некоторых методологиях, например Скрам, архитекторов вообще не предусмотрено.
в некоторых методологиях архитекторов вообще не предусмотрено
Тогда может случиться проблема некомпетентности решений, пусть даже думают над решением много людей, но они не специалисты в вопросе.
Т.е. если ты претендуешь на управление людьми — ты в этой цепочке конечное звено, а не твои подчиненные. И ты самостоятельно оцениваешь производительность, трудоемкость задач, распределяешь нагрузку так, чтобы все нормально работали.
Я уже давно вывел для себя основную оценку компетентности управленца любого уровня — он спускает ниже себя только те задачи, которые действительно требуют участия подчиненных, замыкая в себе все запросы с более высоких и параллельных уровней, которые он может разрулить самостоятельно. И оценка времени решения задачи подразделением — это задача менеджера подразделения, а не его подчиненных.
И оценка времени решения задачи подразделением — это задача менеджера подразделения
пойду закажу эту фразу в золотом тиснении, чтобы в офисе повесить
Поэтому описанные задачи, от которых он ушелВзгляните ещё раз на все упомянутые задачи. Подумайте. И поставьте перед определением «руководитель» прилагательное «художественный». Чувствуете, как изменился акцент?
и да, я долго пишу комментарии…
А как же плач тысяч о том, что мереджеры сроки спускают, не согласовывая с исполнителями?
Кто должен оценку давать? Техдир, как самый общий для всех управленец? Скрам-мастер? Руководители/лиды платформ? Завести 20 управленцев уровня команды?
Так что на каком-то масштабе руководитель ещё что-то способен оценить, но на большем, всё, что он может сделать — не мешать оценивать командам.
Так что на каком-то масштабе руководитель ещё что-то способен оценить, но на большем, всё, что он может сделать — не мешать оценивать командам.
Смысл в том, что команда должна оценивать задачи в попугаях. А конвертацией попугаев в сроки релизов и обещания заказчикам должен заниматься менеджер. Один на всех или свой для каждой команды — это уже от специфики зависит. С учётом того, что скорость работы каждой команды в «своих» попугаях — разная, видится, что это должен быть всё таки «внекомандный» менеджер.
Кто должен оценку давать? Скрам-мастер?
Скрам-мастер — это вообще не менеджер, это статист.
Вот тут «Никто вас не трогает во время спринта, ага?» чинить надо, тогда и менеджеры не понадобятся. Но подойдёт не всем.
Это лютый скилл даже в рамках одной команды
В идеале — это тупая статистика работы команды. Да, в начале проекта её взять толком неоткуда, и тут важен предыдущий опыт менеджера. А потом просто циферки по спринтам сводить. Ну и следить, чтобы скорость команды в попугаях сильно не скакала.
тогда и менеджеры не понадобятся
Достаточно эффективные программисты-менеджеры предпочитают работать соло, а не в команде. Иначе придётся менеджерские задачи решать не только за себя, но и за коллег, а это уже неэффективно для второй сущности человека-оркестра: программистской.
Оценивать в основном статистически. На больших масштабах оценка не зависит от состава задач, а только их количества. Но команды начнут работать гораздо бодрее, если фаза оценки пропадет.
1. Вы пишите:
Поток – это когда есть только скорость. Задачи выстраиваются в очередь, программист садится и решает одну за другой. Сроки не известны, но их можно вычислить – зная скорость и номер задачи в очереди. Главное – не озадачивать вычислением срока самого программиста.
Как вычислить эти сроки? Дано: скорость и порядковый номер задачи, но мы же отказались от того, чтобы считать сроки на каждую задачу. То есть не важно, задача первая или пятая, если я не знаю, сколько уйдет времени на каждую, мне никак порядковый номер не поможет.
2. Представьте, что Вы придумали проект/идею и нанимаете фрилансера. Час его работы стоит 100$. Вы описываете задачу, и, наверное, хотите узнать, сколько он будет её делать. Но у него поток, он отвечает, что он, вообще-то, творец и сроки будут такие, какие будут. И в процессе работы не отвлекайте его, на «митинги». Он сам напишет, когда закончит. При этом у Вас есть бюджет и сроки, и если Вы за них выйдете — решение задачи не имеет смысла. Что делать?
3. У Вас N команд, каждая занимается своей областью. Итоговый продукт — совокупность результатов работы всех команд. Некоторые вещи можно делать внутри команды, некоторые основываются на результатах работы смежных команд. У всех поток. Команда 1 приступает к выполнению задачи, которая зависит от артефактов работы команды 2. Но у тех был поток и они еще не сделали. Хорошо, команда 1 делает что-то другое (менее важное и не приоритетное). Команда 2 доделала, что хотела и начала делать что-то другое. Команда 1 тоже доделала свое не такое важное дело, вернулась и поняла, что есть вопросы (нужна помощь с тем, чтобы разобраться, как работают артефакты команды 2). Но команда 2: уже куда-то переключилась, забыла в чем там было дело, да и из потока выходить тяжело — идет другая задача. Не понятно, как синхронизировать работу N команд если мы отказываемся от планирования?
4. Похоже, что методом потока убирает критерий «скорости» при выборе решений. Многие задачи можно решить большим количеством разных способов, например: в процессе реализации разработчик решил, что новую функцию можно встроить в существующую кодовую базу (чего он делать не любит, потому что «там надо разбираться», «legacy» и т. д.), а можно все переписать, чтобы было красиво, удобно и так, как он захочет. И программист выберет второе. Мы же не спрашивали у него сроки, он ничего не обещал нам, вопрос случился уже в процессе работы и он исходя из тех данных, что у него были выбрал то, что считал лучшим решением, при этом увеличив время реализации в 5-10 раз. Как выбирать решения на основе скорости их реализации, когда мы не оцениваем сроки?
если я не знаю, сколько уйдет времени на каждую
А этого никто не знает, если задача не конвейерная.
Что делать?
Использовать более подходящий под ситуацию метод организации. ;)
Как выбирать решения на основе скорости их реализации, когда мы не оцениваем сроки?
Если основным параметром оценки результата является скорость его достижения, и другие параметры не учитываются или малозначимы, то очевидно, что тоже надо использовать более подходящий метод организации. Не просто так существует фраза: «Искусство управления».
готов прийти в коллектив разработчиков и за деньги сделать x2 продуктивности
А не:
готов прийти в коллектив разработчиков и за деньги сделать x2 продуктивности, если его метод подходит этому коллективу, а если не подходит то там дальше искусство и может не x2, а x0.5 получится, как пойдет.
2.
3. Вы не знаете, о каком потоке идет речь и вовсю упражняетесь в остроумии.
4. У задачи два критерия — правильность решения и эффективность выполнения.
О какой скорости вы говорите? Я могу принять своевременность исполнения, это больше похоже на
деловую дискуссию, а не на выжимки из манагерских книжек
1.2 Про примерный срок: нет, автор явно пишет:
… отсутствует их причина – планирование работы программиста и попытки, так или иначе, оценить сроки исполнения работ ...под так или иначе я понимаю что в подходе автора сроки никак не оцениваются. Я бы не стал писать комментарий, или писал бы совершенно другой, если подход подразумевал примерную оценку сроков. Но он основан на полном отсутствии оценки, что вызывает вопросы.
2. То определение, которое дали Вы — это определение потока как психического состояния. В статье термин поток употребляется в другом смысле, как один из методов планирования. Я сделал такой вывод из следующих фактов:
- Автор сам дает определение этому методу:
Поток – это когда есть только скорость. Задачи выстраиваются в очередь, программист садится и решает одну за другой.
- Автор дает классификацию методов планирования, в которой поток ставится в один ряд с такими методами как Lean, Scrum
Как мне кажется очевидно, что в статье описан поток, как метод планирования, а не как психическое состояние. Но, возможно, я сделал неправильные выводы.
3. Возможно. Свои предположения по этому поводу я описал в п. 2.
4. Да, своевременность исполнения подходит как критерий к тому вопросу, который я описал, спасибо. Но это не отменяет вопроса — если я не оцениваю сроки, я не могу оценить задачу по этому критерию.
И, я думаю, автор имел ввиду «поток», как организацию работы, а не как состояние работника.
Задачи могут различать по трудоёмкости на порядки. Буквально — от нескольких минут до месяцев и лет. А от трудоёмкости зависит и приоритет, и даже сама необходимость задачи.
И если мы говорим не про одну задачу, а про поток задач — даже существенные выпадения небольшого процента задач по трудоемкости мало повлияют на общую картину.
1.2 Никто не спланирует работу специалиста лучше него самого.
Сроки соответственно.
2. Время положительной работы равно времени работы.
Идеальная эффективность.
4. Специалист вам оценит, каждый свою часть работы делает
- Да, вот, со сроками непонятно. От них ведь зачастую и приоритет зависит. Грубо говоря, есть 4 задачи одинаково важные для бизнеса (читай предположительно одинаково увеличивающие прибыль или иные целевые бизнес-метрики). Если вообще никакой оценки сроков или точнее трудоёмкости нет, то вообще без разницы получается. Но по факту одна заняла час, другая — неделю, третья — месяц, четвёртая — год. А Если в этом порядке делать, то заметно больше можно денег заработать, а если в обратном...
Пальцем в небо оценивать?
Если у руководителя нет другой информации на основании которой можно было бы дать оценку, то да, пальцем в небо.
Но обычно у хорошего руководителя работы есть как минимум:
- информация о навыках членов команды и оценка производительности их работы на основании предыдущих проектов/работы в текущем проекте.
- релевантный опыт работы исполнителем решаемых задач и собственный опыт оценки сложности тех или иных задач.
- полномочия определять цели и рамки задач и дробить их на такие, трудоемкость которых проще оценить.
На счет пункта 1 — действительно не понятно так как тут есть только оценка.
Тут необходимо все-таки договориться с человеком о контрольных точках, мол свяжись при достижении прогресса в 20% 40% 80% и покажи промежуточный результат.
Обычно в таких случаях создается рабочая группа по одному человеку из команды 1, 2, n и они являются носителями знаний об артефактах работы.
Тут от продукта зависит:
Если он разовый — тогда все делаем как придется но после релиза продукт отработал свой срок и должен быть утилизирован (не стоит мучить труп) и исполнителя предупредить — мы сейчас это сделаем, оно поживет n месяцев и потом все — проект окончен.
Если продукт постоянный то тут лучше все таки дать выбрать второй вариант это будет прокачивать как сам продукт так и команду так как решая проблемы правильным но долгим путем человек повышает квалификацию, а продукт качество. Если есть важные вехи развития продукта то делать на них акцент.
1 Как вычислить эти сроки? … мы же отказались от того, чтобы считать сроки на каждую задачу
Мы не спрашиваем программиста сколько часов/дней уйдёт на задачу, но мы спрашиваем его какова относительная сложность этой задачи в попугаях. А дальше, зная среднюю скорость каждого разработчика (или команды в целом) в этих самых попугаях (из статистики за прошлые недели), вполне можно прикинуть сроки в часах/днях не озадачивая этим самого разработчика.
2 … нанимаете фрилансера. Час его работы стоит 100$. Вы описываете задачу, и, наверное, хотите узнать, сколько он будет её делать.
Это немного другая ситуация. Фрилансер — это не просто разработчик, это мелкий бизнес из одного человека. Он и менеджер, и бухгалтер, и продажник… а ещё он немного код пишет. Поэтому к нему требования совершенно другие, и с ним вполне нормально обсуждать сроки и бюджет. Это я как фулл-тайм фрилансер с 20-летним стажем говорю.
Но. Есть нюанс. Его продуктивность как разработчика это всё-равно портит. Поэтому и существуют два типа проектов на фрилансе — fixed cost и time&material (почасовка). И поэтому описанная Вами проблема на практике обычно решается следующим образом: Вы начинаете работать с фрилансером, получаете какие-то промежуточные результаты за какое-то конкретное время и деньги, оцениваете устраивает ли Вас такая скорость, стоимость и качество работы, и либо расслабляетесь и позволяете ему спокойно творить в потоке дальше, либо расстаётесь и находите другого фрилансера. Иными словами, если нужна нормальная продуктивность — вариант с фрилансером сводится к тому же самому: поставьте задачи, получите оценку относительной сложности, и не мешайте работать.
3 Не понятно, как синхронизировать работу N команд если мы отказываемся от планирования?
А мы не отказываемся от планирования. Просто планирование заключается не в привязке этапов к конкретным датам, а в выстраивании очереди ближайших задач для каждой команды. И не однократном в момент запуска проекта, а постоянном, потому что порядок следующих задач для одной команды надо подбирать в т.ч. учитывая прогресс соседних команд и зависимости между их задачами. И мы не грузим этими подробностями сами команды, они просто видят, что есть очередь следующих задач, которую менеджер иногда почему-то перетасовывает, а сами просто берут следующую задачу из очереди после завершения текущей и продолжают спокойно работать.
4 Мы же не спрашивали у него сроки, он ничего не обещал нам, вопрос случился уже в процессе работы и он исходя из тех данных, что у него были выбрал то, что считал лучшим решением, при этом увеличив время реализации в 5-10 раз.
Нет, это так не работает. Задачи оценены в "относительной сложности", но для менеджера она всё-равно переводится (им самим) в примерные сроки. И если задача в эти сроки перестаёт вписываться, то его работа прийти к разработчику и выяснить, почему так получилось (точнее, по хорошему, разработчик сам должен прийти к менеджеру в тот момент, когда понял что задача оказалась значительно больше/сложнее, чем указано в её оценке, но если вдруг он протупил и не пришёл — к нему приходит менеджер, просто это случается несколько позднее и впустую теряется больше времени). После чего задача должна быть переоценена (всё ещё в относительной сложности), и дальше менеджер либо снимает её с работы и отправляет куда-то в очередь будущих задач "на потом", либо работы по ней продолжаются.
Важные моменты, на которых всё это держится: во-первых задачи должны быть достаточно мелкими (от 2-3 часа до 2-3 дня работы, в попугаях относительной сложности это 1-2-3-5, максимум иногда ещё можно использовать оценку 8, но это уже сильно на грани и обычно задача с оценкой 8 или выше — это на самом деле задача на декомпозицию, а не на разработку), и во-вторых менеджер сам должен быть достаточно квалифицированным управленцем и быть готов реально заниматься своей работой.
Мы не спрашиваем программиста сколько часов/дней уйдёт на задачу, но мы спрашиваем его какова относительная сложность этой задачи в попугаях.
А что вы понимаете под «попугаями»? По-моему, это те же яйца :) Если я правильно понял автора, его подход позволяет программисту избавиться от ответственности за названные «сроки/попугаи» и не думать о них.
Вот пример из моей деятельности (я не программист) — надо нарисовать сет из 100 иконок для проекта и разработать лого для него. Я скажу, что и то и то займет неделю. Но по сложности эти задачи различаются на порядок. Потому как в случае с логотипом очень много и явных и скрытых «но» и «если».
Вообще что такое попугаи относительной сложности описано довольно неплохо и много где, но могу пересказать своими словами. :)
Смотрите:
- Почему именно относительная сложность. Очевидно, что джун и сениор сделают одну и ту же задачу за (иногда — сильно) разное время. Соответственно, если оценку в часах привязывать к задаче без учёта того, кто её будет делать — получается уже слишком большая погрешность (по сути — в разы). А относительная сложность задачи от исполнителя не зависит.
- Почему именно попугаи. Если спросить разработчика "за сколько сделаешь таску" и он назовёт "4 часа" — это обеими сторонами воспринимается как commitment, и начинает "нависать" над разработчиком, напрягать его — со всеми вытекающими последствиями для его продуктивности. А вот если спросить "насколько эта задачка сложнее вон той" — он ответит "раза в 2-3" не напрягаясь, потому что никакого commitment здесь нет, по крайней мере он этот ответ не воспринимает как обязательство делать эту задачу не дольше чем в 3 раза относительно первой.
Тем не менее, для менеджера все эти попугаи нужны уже переведёнными в часы, иначе сложно планировать работу с точки зрения бизнеса. Поэтому он (в уме) переводит попугаи в часы примерно по такой схеме:
- Относительная сложность задачи 1: 15 мин — 2 часа
- Относительная сложность задачи 2: 3-4 часа
- Относительная сложность задачи 3: 5-8 часов
- Относительная сложность задачи 5: 2 дня
- Относительная сложность задачи 8: 3-4 дня, но лучше бы декомпозировать
Дальше, как только он перевёл эти оценки в часы — они сразу стали зависеть от того, кто будет этой задачей заниматься (сениор/мид/джун), есть ли у него опыт с задачами такого типа, etc. (Цифры выше приведены для сениора либо имеющего опыт в задачах такого типа миддла, для джуна эти часы надо умножать на 2-3.) И чтобы влияние этих факторов нивелировать на помощь приходит статистика: сколько в сумме (складывая значения относительной сложности, а не часы) попугаев закрывает данная конкретная команда за неделю. Если команда состоит из сениоров и крепких миддлов — цифры обычно примерно сходятся, в смысле указанные мной выше в сумме дадут по 30-40 рабочих часов на члена команды (30 — потому что задачи же всегда недооценивают, и по факту они немного сложнее, чем были оценены).
Конечно, тут не всё прям так линейно. Задачи сложностью 8 можно давать только сениорам и очень хорошо знакомым с задачами такого типа миддлам, если её дать джуну он может уйти в аут на три недели и не сделать в результате. Если у нас пачка на 20 задач сложности 1 — они будут сделаны намного (в разы) быстрее, чем 10 задач сложности 2.
Тем не менее, этот подход позволяет менеджеру получать достаточно точные оценки как объёма работ который будет сделан командой за неделю-две, так и довольно точную дату когда будет закрыта конкретная задача — причём не напрягая разработчиков!
Я честно говоря не понял в чем отличие той же оценки в store points, которую рекомендуют в agile. Там даже методика есть как их превращать в реальные сроки.
Ни в чём, это она и есть. То, что я описал выше — немного упрощённый вариант, когда оценку даёт один разработчик на конкретную мелкую (после декомпозиции) таску, которую вполне возможно он и будет делать. Вариант в Agile подразумевает скорее коллективную оценку более крупной бизнес-таски, которую оценивают всей командой (planning poker). Но суть оценки та же — относительная сложность задачи. Только там и масштабы цифр немного другие, бизнесовая задача сложности 1 — это обычно 2-3 дня работы, потому что она включает какой-то мелкий фикс на бэке, соответствующую правку на фронте, ручное тестирование и выкат, со всеми прилагающимися коммуникационными задержками в процессе.
Получается что разница лишь в коллективной оценке? Так она там не спроста была придумана, так как один человек не всегда сможет адекватно оценить задачу. Оценка командой повышает точность в виду разной квалификации и опыта разработчиков в команде.
Я не сказал, что не надо декомпозировать. Просто там результат декомпозиции — это всё ещё относительно крупные задачи, потому что это всё ещё бизнес-задачи. Перед тем, как ими можно будет заняться конкретным исполнителям бэка/фронта/тестировщикам/девопсам эти задачи потребуется декомпозировать на ещё более мелкие.
А польза от коллективной оценки вызвана именно тем, что в этих, более крупных бизнес-задачах зачастую есть элементы разных частей системы (бэк/фронт/etc.), поэтому полезно узнать мнение всей команды. В то же время более мелкие задачи чисто бэка, которые реально пойдут в работу после декомпозиции этой бизнес-таски, просить оценить коллег с фронта или тестировщиков совершенно бессмысленно, равно как и наоборот.
Что до коллективной оценки исключительно внутри команды бэка (фронта, etc.) их собственных задач, то да, конечно, точность-то это увеличит… только вот пользы от этого не будет, а будет исключительно вред. Дело в том, что такая точность никому на самом деле не нужна, а время на согласование коллективных оценок всей командой тратится довольно значительное (потому что задачи мелкие и их много), поэтому из соображений повышения продуктивности обычно такие оценки выставляет либо тот разработчик, который заводит задачу, либо тимлид, не собирая очередной малополезный митинг без реальной необходимости.
2. Соглашусь с Вами, этот вопрос наверное неуместен. Фрилансер должен быть сам себе менеджер.
3. и 4.
Я согласен с Вашими доводами. Но это очень сильно похоже на scrum, но только без спринтов. Главный вопрос: в Вашем описании сроки все таки есть, мы от них не отказываемся, чтобы планировать, чтобы следить за результатом и пр. Но мы скрываем эти сроки от разработчика. И для разработчика происходит именно то, что и должно по закону Паркинсона (в том виде, в котором этот закон представлен в статье) — задача займет столько, сколько на неё есть времени, а время оказывается не ограничено и задачи перестанут завершаться совсем.
То есть моя мысль: или закон Паркинсона не работает, или он работает, но тогда отсутствие ограничения по времени для разработчика должно превращать все задачи в бесконечные.
1. А почему точность оценки сложности у программиста будет выше, чем точность оценки сроков? И какая разница спрашивать сколько в часах или сколько в попугаях, если перевод из одного во второе осуществляется умножением на константу?
В том то и дело, что не на константу. Пример «попугаев» в оной из команд:
- Задача может иметь одну из следующих оценок в попугаях: 1-2-4-8
- Программист в среднем в неделю (5 рабочих дней) вырабатывает 20 попугаев
- Задач сложностью в 1 попугай можно сделать 5-8 штук в день
- Задач сложностью в 2 попугая можно сделать 3-4 штук в день
- Задача сложностью в 4 попугая делается в течении одного или двух дней
- Задач сложностью в 8 попугаев кандидат на декомпозицю или делается 2-3 дня
Вы же все равно, как разработчик, будете оценивать задачу для себя в часах — попробуете вспомнить, сколько делали похожую задачу раньше. Представьте, что Вы попали в новую фирму, где используются те самые попугаи. Как Вы будете оценивать свою первую задачу? Скорее всего попросите у руководителя таблицу перевода попугаев в часы конкретно в этой команде этой конторы. Но зачем это промежуточное число, когда можно не переводить ничего никуда и остаться в примерном времени?
Судя по статье автора — чтобы у Вас не было ограничения по времени. Но тогда и делать одну задачу Вы будете вечно.
В чем принципиальная разница спрашивать у разработчиков сроки в попугаях или часах?
Мне стало понятно из этого ролика:
Learn agile estimation in 10 minutes
TLDR: точные оценки не точны, относительные точны. Особенность психики.
Представьте, что Вы попали в новую фирму, где используются те самые попугаи.
Попугаи те же, но вес другой. Попугаи калибруются под связку проекта и команды. То есть если проект поменялся, или команда изменилась, даже если один человек пришел или ушел, попугаи нужно снова калибровать.
Скорее всего попросите у руководителя таблицу перевода попугаев в часы конкретно в этой команде этой конторы. Но зачем это промежуточное число, когда можно не переводить ничего никуда и остаться в примерном времени?
Таблица перевода должна быть динамической и основана на исторических данных как минимум за один спринт. Если это не так, то это agile курильщика.
И да agile — это сложно в первую очередь для менеджера, он для этого и стоит над исполнителями. Голова у него не только, чтобы оценки тех.люда агрегировать и проксировать стейкхолдерам
cc SHLab
Добавлю, что agile это не только сложно, но в принципе подходит далеко не для всех команд и проектов, чтобы адепты не говорили.
А почему точность оценки сложности у программиста будет выше, чем точность оценки сроков?
По ряду причин. Во-первых, оценка сложности выдаётся в более приблизительных 1-2-3-5-8 единицах, нет необходимости выбирать "таки 5 часов или 6?". Во-вторых исключаются тупые встречные вопросы вроде "а чего так долго? а если оценим на два часа меньше сможешь справиться?" и т.п. В-третьих если разработчик не выработал привычку тщательно отслеживать сколько часов он на что тратит (а такую привычку обычно вырабатывают только фрилансеры работающие на почасовке), то он тупо не знает сколько времени это займёт — но при этом вполне в состоянии оценить насколько одна задача сложнее другой.
или закон Паркинсона не работает, или он работает, но тогда отсутствие ограничения по времени для разработчика должно превращать все задачи в бесконечные
Скажем так. Он работает в том смысле, что если разработчика вообще не дёргать, то он даже задачу относительной сложности 2 способен превратить в рефакторинг на месяц-два. Но когда разработчик знает, что если его скорость закрывания задач начнёт слишком сильно отличаться от ожидаемой (см. таблицу соответствия часов и относительной сложности выше), то к нему обязательно придёт тимлид или PM с вопросом "а что, собственно, происходит, где затык?", то задачи в бесконечные уже не превращаются. Более того, разработчики вообще-то должны значительно раньше (как только увидели, что в ожидаемое среднее время для задач такой сложности они точно не вписываются, и срок явно будет сорван не на несколько часов, а на несколько дней) сами прийти к тимлиду и сообщить, что сложность задачи была оценена неверно (что дальше приводит к переоценке задачи, и либо её отмене, либо возврату в бэклог на потом, либо декомпозиции, либо продолжению работы но уже с учётом другой оценки).
Во-первых, оценка сложности выдаётся в более приблизительных 1-2-3-5-8 единицах, нет необходимости выбирать «таки 5 часов или 6?»Я не за оценки времени, но все же слышал что есть вариант выбирать экспоненциальную оценку: 1, 2, 4 часов, 1, 2 дня, 1, 2 недели. И программист не выбирает 5 или 6 часов, 5 или 6 это больше 4-х часов значит 1 день.
Но я с обычными оценками времени поработал полтора месяца и мне больше не хочется. Делаешь задачу вовремя — ок, можно чай попить без нервов. А если сам не успеваешь делать те задачи которые сам оценивал в часах — давит на психику.
Я вообще давал время согласно логнормальному распределению, например: с вероятностью 50% сделаю за 4 часа, с вероятностью 80% сделаю за 2 дня, с вероятностью 99% сделаю за 2 недели. Но менеджерам это почему-то не понравилось, хотя это явно наиболее приближенное к реальности.
1 кто такие «Мы»? С кем вы собрались делить ответственность за принято решение?
как уже писали вы, когда вы уже достаточно долго работаете с разработчиком вы можете примерно подсчитать за сколько он закончит, да есть нюансы, но статистическая выборка по нюансам у вас так же повится. А как именно считать уже ваша зона ответственности по предложенной методике. Если не сходится значит вы что-то делаете не так.
2 Если клиент не может обеспечить достаточный бюджет в этом виноват он, а не вы и не программист и в прямой трактовке вопроса он уже содержит ответ. Да задача не имеет смысла.
С другой стороны вы как менеджер всегда можете договорится с клиентом(дальше предположение), например позволить оплатить выход за бюджет позже, если он будет
3. для решения этого вопроса есть простой метод: документирование, нормальные программисты обычно оставляют хоть что-то, если в коде есть сложные моменты.
Соответственно перед началом проекта принимаем требования о минимальной документации, это не говоря о том что есть социальные соглашения которые можно встроить прямо в код, и другие соглашения которые призваны решить возникновение таких проблем
4. вы путаете понятия, запилить фичу и всё переписать это две разные задачи, программист должен уведомить об этом менеджера.
К тому же переписание с нуля протеворечит одному из принципов программирования, который на обычный язык переводится как: Работает — не трож.
2) Фрилансер — это не просто программист, он сам себе ещё и менеджер, так что в данном случае это его задача — давать оценку срокам и стоимости, на основании своих знаний о своей скорости работы над задачами. Если вы его нанимаете для разового проекта — вы вправе ожидать оценки. Если вы его нанимаете на долговременной основе, без конкретных задач, а, например, для постоянной работы над проектом — то вы уже можете сами собирать статистику, тогда возвращаемся к ответу на первый пункт.
3) Если N команд независимо друг от друга пилят куски общего проекта — куски должны быть независимы друг от друга. Взаимодействие между компонентами должно быть документировано(и соответствовать документации). В противном случае, независимо от того поток у вас, скрам, канбан, аджайл, водопад или что-то ещё — команды постоянно будут зависеть друг от друга, и оттягивать сроки из за внешних(с точки зрения одной команды) проблем.
4) В задаче должно быть прописано выбранное решение. Если программист сам выбрал вариант, увеличивающий время разработки в десять раз, и при этом не удосужился описать это в задаче, этот процесс не был проконтролирован тимлидом, об этом не знает менеджер — мне кажется что-то изначально плохо в процессах. При этом, оценка среднестатистической скорости решения задачи всё ещё доступна — если у вас все программисты в среднем каждую десятую задачу делают в 10 раз дольше из за того что принимают решение провести рефакторинг — то 10 задач у вас решаются за 20 условных единиц времени, и пятая задача в очереди будет готова через примерно 10 средних единиц времени. Улучшить точность можно так же как и в первом ответе — оценка задач тимлидом в условных попугаях, декомпозиция их до уровня атомарных задач в один попугай, и т.д.
В задаче должно быть прописано выбранное решение.
И кто должен его выбирать? И что делать, если для выбора решения нужно потратить много времени? Например для задачи реализации полнотекстового поиска я сейчас даже не скажу какие варианты более-менее популярны.
2) Техлид. Опять же, если он есть — он тоже может решить, какое решение в данном случае выбрать. Хотя есть стоит выбор между костылём и рефакторингом, это всё же не к нему.
3) ПМ. В ответ на вопрос программиста — фигачим костыль по быстрому и копим техдолг, или у нас есть время нормально отрефакторить?
4) Сам программист. В рамках отдельной задачи по ресёрчу. Это если нужно именно выбрать, что и как реализовывать. Если выбор между костылём и рефакторингом — всё ещё лучше задать этот вопрос тимлиду или ПМу.
- Сложность ни как не связана с трудоемкостью или как вы любите со сроками. Вообще, воот совсем ни как, да есть исключения, но это не ваш случай
- Срок завершения работы это не дата, это функция распределения вероятности
- Если хочется узнать дату завершения работы, используйте статистику. Не спрашивайте людей.
- Основная задача менеджера понимать что такое ошибки первого и второго рода
и стараться избегать их - В текущих методологиях и фремворках все уже есть. Просто используйте те что вам подходят
В итоге либо у вас конвейер с одинаковыми задачами и одинаково хорошо работают методы фантазии, резерва, объема и потока, либо у вас поток непонятных задач и никакие подходы нормально не работают.
С потоком есть еще такая проблема. Чаще всего вы не доверяете программисту полностью, он может просто не справится с задачей. Это особенно верно для непонятных задач, которые он раньше не делал. Не зная предварительных сроков вы не можете оценить вероятность провала. А если задачу оценивали в 2 недели, прошло 3 а показать еще нечего, то похоже пора остановиться и либо отказаться от задачи либо передать ее кому-то еще или сесть и сделать самому.
Статистика, тем не менее, штука крайне полезная и ее нужно собирать и применять в любом стиле планирования. В моем опыте качество специалистов определяет успех или провал, а не качество планирования. А вот подход — мы оставим ту же команду, но изменим метод планирования ни разу не сработал.
Если программисты перестают париться насчет сроков, и просто решают задачи, одну за другой, ни на что не отвлекаясь, то продуктивность возрастает вдвое. Соответственно, если включить режим «успевания в срок» обратно, то коэффициент ровно тот же – вдвое, только на этот раз продуктивность на него делится.
Удивительно, что для кого-то это не очевидно.
1. Считать сроки это тоже работа. Работа требует времени.
2. Работа с постоянными дедлайнами увеличивает стресс, который съедает часть сил сотрудника — его производительность падает.
Самое забавное, когда просят дать оценку сроков на баг. В чем баг еще непонятно, как его решать, и на сколько это будет трудоемко непонятно, но оценку времени давай сейчас.
Спасает только то, что в 90% компаниях к срокам относятся также наплевательски, как и ко всему остальному — т.е. не уложился, ну и ладно.
Оценку на баг дать не сложно. По сути, большая часть времени уходит на поиск бага, исправление в большинстве случаев занимает минуты. Время на поиск бага обычно довольно чётко коррелирует с тем, в какой области проекта проблема и насколько хорошие инструменты/техники отладки/покрытие тестами доступны для этой части проекта. Поэтому баг оценивается обычно исходя из известной части: сколько времени мы примерно обычно ищем баги такого типа в этой части проекта.
За то время, в которое баг был оценён, обычно удаётся либо его найти и пофиксить, либо выясняется достаточно подробностей, чтобы переоценить баг намного более точно (и после этой переоценки менеджер вполне может решить, что больше этим багом прямо сейчас заниматься вообще не нужно).
Оценку на баг дать не сложно.
Хм… либо вам очень повезло с багрепортами, либо очень несложная система, либо вы гений.
В большинстве случаев всё совсем не так просто:
- Баги консистентности (что из-за concurrency, что в СУБД) ищутся и лечатся непредсказуемо неделями.
- Баги в сложных алгоритмах — да у меня иногда уходило по паре дней, чтобы просто вспомнить (не понять!) как алгоритм должен работать. При детальных комментариях, хороших примерах и т.п.
- Баги расчетов в крупных БД — да даже если понятно что воспроизводить, но привести БД в нужное состояние может занять пару дней. Или недель.
- А часто баг-репорт это кейс с прода. Полного доступа нет и не должно быть. Как вопросизводить — а фиг знает.
- Баги на специфичном оборудовании (ахаха, через неделю станет ясно, что китайская железка сглючила из-за китайского питания).
- Баги в любой сложноотлаживаемой среде (или среда многокомпонентная или, например, ОС)
- Баги, требующие для исправления пересмотра архитектуры.
- Баги в чувствительной к безопасности компоненте. А теперь баги в чувствительной к безопасности и критичной по производительности компоненте?
- Баги в голове багрепортера. Задача со звёздочкой: баги в голове багрепортера, который является главным источником требований.
- Баги в апстриме или внешних зависимостях. А если эта зависимость — фреймворк с закрытым кодом?
К тому же эта неопределённость в трудоёмкости так или иначе есть во всех этапах жизни бага: и в регистрации, и диагностике, и в поиске минимально воспроизводимого примера, и в проектировании исправления, и в исправлении, и в последующем написании тестов, и в отладке тестов, и в сборке, и в последующей доставке до рабочей среды, и в самой процедуре развёртывания. А оценить требуют примерно после регистрации. Я не спорю, что есть относительно много багов, которые просто оценить — процент зависит от качества багрепортов, сложности продукта и личных способностей участников разработки, но ведь если разработка ведётся достаточно качественно, то такие простые баги просто не долетают до регистрации, и остаются либо совсем некритичные, либо хардкор.
Хм… либо вам очень повезло с багрепортами, либо очень несложная система, либо вы гений.
Ничего из вышеперечисленного. Я обычно работаю с микросервисами (что уже сильно уменьшает размеры и сложность каждой части системы и увеличивает изоляцию между ними), с использованием чистой архитектуры (что упрощает тестирование), с хорошим покрытием юнит-тестами и немного интеграционными (что упрощает проверку найденных багов и их исправление), ну и всякое другое по мелочи (напр. документация до кода и генерация кода из swagger.yml/protobuf, ревью кода, CI/CD, жёсткие линтеры, подход defect-free при котором баги не копятся в трекере, etc.). Иными словами — фокус делают хорошо поставленные процессы разработки, а не чья-то гениальность.
В большинстве случаев всё совсем не так просто:
Все эти сложные кейсы, тем не менее, можно разделить на какие-то этапы. И, как минимум для первого этапа — дать относительно адекватную оценку. В самых-самых запущенных случаях — это может быть оценка на "попытаться воспроизвести" или "оценить трудоёмкость первого этапа". В конечном итоге речь ведь вовсе не о том, что нужно обязательно сказать за сколько часов баг будет исправлен — это бы сильно всё упростило для менеджера, но это не всегда возможно — а о том, что нужно дать менеджеру хоть какую-то информацию, на основании которой он сможет решить когда придёт время заняться этим багом. И эта информация вполне может поступать к нему по частям: сначала нужно 2 часа на то, чтобы понять в какой подсистеме проблема и сколько потребуется на её воспроизведение; через 1-3 часа можно ему сообщить, что на воспроизведение нужно ещё от 4-х часов до пары дней, и т.д. — чтобы он имел возможность в любой из этих точек принять решение "так, стоп, откладываем этот баг на потом".
Ничего из вышеперечисленного.
На самом деле вы просто работаете с достаточно простой системой/системами. Отчасти она простая вследствие ваших действий (микросервисы, чистая архитектура, юнит-тесты, хороший пайплайн, отлаженный процесс), отчасти наоборот — приёмы допустимы потому что система простая.
И, как минимум для первого этапа — дать относительно адекватную оценку. В самых-самых запущенных случаях — это может быть оценка на "попытаться воспроизвести" или "оценить трудоёмкость первого этапа".
Для кейсов отличных, от тривиальных, эти оценки лично я дать не могу.
Вот пример. В начале 2007 года, на внедрении системы учета в производстве (1С, если любопытно), была проблема. В рандомный момент времени ВСЯ система падала (клиенты, сервер приложений, SQL Server 2005 SP1). Ну ОК, первые раза два никто ничего не понял, но потом при минимальном разборе сразу можно было сказать — всё падает, потому что падает SQL Server — точнее возникает эксепшен 20 северити, кладётся минидамп, отваливаются клиенты и нужно рестартовать сервис. А всё остальное падает прицепом. Критичность — шо пипец, каждый раз больше сотни сотрудников фабрики встают примерно на час. HADRы и прочие кластера не факт, что спасут (да и перейти на них недёшево и не за неделю). Директор фабрики на четвёртый раз, конечно, спрашивает — "Доколе?". Что же ему ответить?
Относительно нормально собрать диагностику получилось разу к седьмому-восьмому (падения не каждый день, конечно). Ну как "нормально" — это был запрос SQL, на котором сервер падал. В выходные получилось воспроизвести именно падение сервера, но на поиск из-за чего возникает этот запрос ушло еще несколько дней. Выяснилось, что запрос генерируется системой при просмотре списка документов с определённым фильтром. Запрос достаточно разумный. То есть падение может вызвать любой пользователь и сделать с этим ничего невозможно.
Пользователей, конечно, проинструктировали, но реально это как на бочке с порохом.
У меня ушло несколько дней на создание минимального репро, который зависел от структуры таблиц, данных в ней и запроса. Через несколько недель уже летом 2007 года MS зарегистрировал ошибку, а с 1С общение было более медленным и реально не в 1С проблема. Тем временем вышел SP2 — в нём тоже сервер падал. Воспроизводилась в RTM/SP1/SP2. На SQL Server 2000 не воспроизводилась, но официально купить его уже было невозможно.
Багу MS исправили только в октябре 2008 года в SP2CU10, через пару месяцев SP3 вышел, а чуть раньше в августе SQL Server 2008 — в нём тоже не было баги, но у него были свои проблемы, да и переход не бесплатный. Пара лет почти.
Собственно, в этой длинной истории вопрос простой: какую оценку и в какой момент можно было озвучивать, кроме "это самая приоритетная задача"? И это еще нам повезло, что пользователей было мало и мы тупо могли всем сказать как нельзя делать (хотя реально действия безобидные). Повезло, что репро получилось сделать, у меня есть несколько примеров, где репро не получалось сделать (ошибка в продукте вендора исправляется тогда только почти случайно в одном из следующих мажорных релизов).
какую оценку и в какой момент можно было озвучивать, кроме "это самая приоритетная задача"?
У меня тоже случались похожие кейсы. В частности, есть у меня смутные воспоминания про какой-то баг в MySQL, который то ли я завёл лет 15 назад, то ли нашёл в их трекере уже открытый (после того, как сам доотлаживался достаточно глубоко, чтобы его выявить, и понять, что именно искать в трекере).
Тем не менее, это никак не влияет на возможность дать оценку. Конкретно по Вашему примеру:
- Сначала можно дать оценку "мне надо X часов на изучение логов в момент падения".
- Потом, если по логам ничего не нашлось, можно дать следующую оценку "мне надо Х часов на внедрение дополнительного логирования/включение debug-режимов/etc.". После чего баг обычно ставится на паузу до следующего раза (если у компании полно лишних ресурсов и баг критичный — можно выделить X часов на активные попытки делать всё что приходит в голову с системой в надежде что повезёт вызвать баг).
- Когда по логам стало что-то ясно, то можно дать следующую оценку "мне надо X часов на то, чтобы поднять отдельное тестовое окружение и воспроизвести баг в нём, и потом ещё Y часов на попытки минимизировать количество задействованных в воспроизведении элементов окружения".
- Когда баг зарепорчен вендору и возможность фикса заблокирована — оценка 0, потому что лично мы ничего сделать всё-равно не можем. А если вендор опенсорсный и у нас в компании есть достаточная для фикса экспертиза — то вполне можно оценить таску на багфикс как при обычной разработке, форкнуть и сделать самим, когда до неё дойдёт очередь (правда, тут возникает дополнительный тех.долг на поддержание форка и пропихивание фикса в апстрим, но это другая история).
И так далее. Садясь что-то делать — в голове сначала должен быть план, что именно — а, значит, этот конкретный план вполне возможно оценить. Иногда бывают задачи, когда конкретного плана нет — напр. когда задача хаотично потестировать сервис вручную (чем можно заниматься совершенно любое количество времени, продолжая временами что-то да находить) — в таких случаях обычно оценка ставится не на основе плана действий (ибо невозможно), а на основе имеющихся ресурсов (на тестирование выделяется 2 дня, что найдём за это время — то и починим). Чаще бывают исследовательские задачи, когда нужно изучить неизвестную область, в которой можно копаться неизвестно сколько времени — но и такие задачи без проблем оцениваются: сначала выделяем 2-3 часа/дня на первичное изучение, по результатам которого станут ясны объёмы задачи и получится дать уже вполне осмысленную оценку сколько там ещё надо копать.
В целом, проблема с оценкой чаще всего вызвана тем, что люди садятся работать не очень-то понимая, что конкретно нужно сделать и какой конкретно результат от них требуется, и разбираются с этим вопросом уже в процессе работы. Не надо так делать, сначала надо поставить простую и конкретную задачу, с чётким DoD (Definition of Done) — даже если это задача "понять, какую задачу надо решить" (в особо запущенных случаях бывает и такое, очень редко, но бывает). Тогда и оценивать задачи станет намного проще, и работу работать тоже станет проще.
Сначала можно дать оценку «мне надо X часов на изучение логов в момент падения»…
… в голове сначала должен быть план…
Ну, уважаемый, Вы какие-то прописные истины озвучиваете.
Понятно, что информировать по мере выполнения этапов — лучше и правильней, чем говорить «не знаю, будет когда будет», вот только первоначальную проблему Вы этим не решаете.
Начальнику завода (или кому там) вообще до фонаря, сколько у вас займет каждый из этапов. Ему важно знать когда будет результат, потому что ему банально нужно подсчитать сколько денег он за это время потеряет (и не выгоднее ли будет на время перейти в «ручной режим», сменить текущее решение или вообще закрыть завод).
UPD: Речь шла о критическом баге из предыдущего комментария, когда вопроса «закрывать баг или оставить на потом» не стоит вообще, но применимо и к любым продуктовым «фичам», когда нужно заранее оценить, стоит ли вообще эту фичу добавлять, например, в текущую версию.
Мечтать не вредно. Понятно, что ему важно это знать, но если никто не может ему эту информацию дать, значит ему придётся как-то обойтись без точных данных.
Просто выбирая между вообще бесполезным ответом "я без понятия сколько времени это займёт и получится ли решить задачу вообще" и частично полезным "сначала надо X времени чтобы сделать первый этап задачи, а потом я смогу дать более точную оценку по следующим этапам" — выбор вроде очевиден. И второй тип ответа воможно дать всегда, в отличие от первого. Соответственно, моя позиция в том, что оценку дать можно всегда, не всегда это финальная оценка, но лучше хоть какая-то, чем никакой.
Нетиповые, коих большинство в развивающемся проекте (если мы о фичах) или тяжелом легаси (если мы о багах… да и о фичах тоже), оцениваются сложно и только для оценки даже возможности внедрения/фикса требуется от Х до У времени, где и Х и У заранее неизвестны.
Вы предлагаете разумный компромисс с поэтапностью — это да. Адекватные люди так и работают в большинстве случаев.
Вот только рядовому куратору проекта в идеале очень хочется знать «а можем ли мы сделать вот это вот до дд.мм.гггг и сколько нам это будет стоить?» и ессно желательно без вбухивания ресурсов в задачу «выяснение, а сможем ли мы сделать нужную задачу».
И узнать очень желательно прямо сейчас, а не через неделю, потому что часики тикают и решение о внедрении принимать нужно как можно раньше — если фичу сделают, но через день после презентации очередной версии клиенту, то собсна могли бы и не делать прямо сейчас, а сделать что-нибудь другое.
Мне один раз пришлось долго объяснять, почему предыдущую задачу «увеличить точность отображения вот этой штуки в отчетах до сотых долей» заняло десять минут, а следующая задача с похожей формулировкой займет по предварительной оценке более десяти часов.
На практике все эти проблемы — не совсем проблемы.
С одной стороны, понятие "типовая" фича/баг субъективно и сильно зависит от опыта исполнителя. (Напр. у меня 30 лет опыта, и в своей области бэкенда-микросервисов я крайне редко сталкиваюсь с "не типовыми" для себя задачами.)
С другой стороны, если менеджер тупой либо не имеет опыта в IT и не хочет вникнуть в специфику IT — это его проблема, и не надо делать её своей: кто-то один просто должен уйти, либо менеджер либо разработчик (стандартное правило не работать на плохих проектах).
С третьей стороны, всегда есть альтернативный подход (упомянутый в статье) — резерв. Если менеджер хочет услышать прямо сейчас цифру, которую неоткуда взять — ему называется цифра с достаточно большим запасом, чтобы перекрыть большинство возможных рисков. Она, конечно же, ему категорически не понравится (потому что, будем откровенны, для целей планирования она бесполезна), но другой цифры у меня для него в этой ситуации нет. Если он решит эскалировать эту ситуацию и будет требовать другие цифры или назначит цифру с потолка сам — то ситуация сведется к предыдущей — один из нас должен будет с проекта уйти.
Не очень понял про эффективность скрама. Там же ежедневные часовые стенд апы, где ты зачем то отчитываешься на каком ты этапе решения задачи и как скоро ты ее решишь и слушаешь зачем то чужие отчёты. Скрам это постоянная непрерывная прогулка-гонка, где при каждом переходе проезжей части включается секундомер а вся прогулка состоит из непрерывных переходов проезжей части, зачастую туда обратно. Скрам не увеличивает эффективность ни в два раза, ни в полтора, это самое большое зло, созданное туповатыми янки для управления другими туповатыми янки и по обезьянней привычке подражать перенятое остальным цивилизоаанным миром.
А в остальном с автором согласен, разве что сроки при спокойной работе прогнозировать можно и с небольшой погрешностью.
И только на Васю день за днём льются потоки чуши, от которой он день за днём продолжает защищать команду. Невесёлая судьба тимлида вполне успешного проекта.
Покажите мне человека, который прекрасно разбирается в людях настолько что способен разобраться в причинах и погасить любой человеческий конфликт или дайте мне методику как такого человека определить на собеседовании чтобы взять тимлидом. И очевидно что hr кто будет брать такого человека должен разбираться в людях не хуже его и тогда где найти такого hr-а. Человеческая область — сложное искусство, поэтому лучше чтобы Вася был профессионалом и набрал себе профессиональных исполнителей. А конфликты — часть работы. Если в коллективе нет конфликтов значит людям все равно и это тревожный звонок.
Покажите мне человека, который прекрасно разбирается в людях настолько что способен разобраться в причинах и погасить любой человеческий конфликт или дайте мне методику как такого человека определить на собеседовании чтобы взять тимлидом.
Ловите методику: никогда такой человек к вам на собеседование не придёт, поскольку с такими скилами глупо идти работать на дядю, надо идти мир захватывать :)
И в итоге ты месяц работаешь в «потоке» когда изобретаешь новые подходы к решению технических проблем отрасли, составляешь мат. модели процессоров разомкнутых систем с 2х-3х производительностью с работой по ночам и с перерывами на сон и самое главное — тебе это нравится ибо ты делаешь то, от чего тебя прет и это дает результат!, а потом начинается… Тут надо документик сделать для тех вот чуваков, и потом еще один надо составить… Ну, а кто это может сделать кроме тебя? Ты ж все разрабатываешь и ты в курсе всех нюансов (аутсосреров хер заставишь родить бумажку. Хоть какую), да и больше некому. И документ должен с одной стороны быть понятен очень гуманитарию и очень техническому специалисту с другой стороны.
В итоге ты в течении 2 дней выходишь с потока (пытаешься вспомнить какой сейчас год, кто все эти люди и вообще какая сейчас валюта в обиходе)… Начинаешь составлять какие-то документы по системам которые разрабатывались 2-3 года назад с непрозрачными требованиями по наполнению содержания документов и эффективность предсказуемо падает в 3-4 раза!.. И это все еще нужно вести в project/task management ПО. А потом снова за код/алгоритмизацию/исследования ибо R&D!
Но, когда ты спрашиваешь чтобы нанять в команду Project Managerа!!!1/ Product Ownerа или хотя бы тян, чтобы скрасить серые трудовыебудни — ну, а что они будут делать? Вы сами не можете свои задачи спланировать что-ли?
Много копий было сломано в дискуссиях с руководством о работе программиста… но все сводится к «Ты сначала напиши себе ТЗ, а потом его исполняй, но перед исполнением запланируй разработку всего проекта и тасков, а еще время от времени мы тебя будем дергать на писанину документов не важно чем ты сейчас занимаешся»! Тыжпрограммист, а значит — универсальный солдат :)
Хухх, выговорился. Полегчало. Пойду дальше составлять technical file:)
Вот только недавно прочитал статью на тему, что сроки все-таки нужно ставить. Даже самому себе, иначе будешь все время тратить на одно и тоже, так как спешить некуда.
То есть, нельзя давать сроков, но они все-таки нужны?
Так себе подход, если честно. Отлично подходит для аутсорса, но не продуктовой разработки, потому что ведёт к постоянному увеличению тех.долга. Очень плох для задач, где важна надёжность и/или безопасность. В общем, говнокод не везде уместен, если одной фразой.
Зависит от мотивации и квалификации, у меня был проект который я делал 3 месяца в одиночку. Никто меня не трогал, сроки не ставил. Тех задания не было (два предложения не считаю тз).
Да было программирование ради программирования как на фронте (React + MobxStateTree + Graphql) так и на бэке (TDD, DDD, Layers, Queues, Chanels and Filters).
Было изучение тематики целой предметной области (вероятностный и бинарный скоринг), поиск информации, разговоры с будущими пользователями, проектирование архитектуры и документация.
Итог — проект запущен, работал как часы, обрабатывал 65,000 клинетов в день, снял нагрузку с call центра, и каждый месяца приносил компании почти 1 миллион в рублях (мне об этом сообщили уже когда я ушел).
Будем экстраполировать по одной точке?
Я понимаю что приятно рассказать свою историю. Но неплохо бы при этом на индустрию не обобщать
С тем же успехом, с той же мотивацией и квалификацией в подобных условиях можно завалить компанию на минус «почти миллион в рублях в месяц».
А последнее — это сильно попахивает Канбан. И его тоже стоило бы применять. Я бы даже сказал, пошагово внедрять. И да, как раз этим должен заниматься манагер, чтобы не нужно было попадать в «бутылочное горлышко».
При грамотном подходе Scrum
Вы в жизни такое видели? Чтобы не на неделю-две, а надолго.
Вы в жизни такое видели?в точку. Только 1 раз. И то прихрамывало. Все равно что-то выходило из под контроля — как правило воспринималось в штыки из-за недопонимания: «Меня хотят контролировать, а я этого не хочу. Лучше обосрать методику, пока ее не внедрили.» Где-то неприменимо, так как работали люди не над одним продуктом, мало того — в разных стеках технологий или программисты были не софтверы, а «на заводе». Ну и до кучи самодурство в руководстве, которое не знало, чем занять «программиста, который ничего не делает», либо проявить инициативу — внедрить новую модную технологию (но результат, как в «Вычитал. Хочу. Делайте»). Но если внедрять систему по уму, то толк будет.
PS: Пользуясь случаем, хочу сказать. Иван, ты — крут! Обожаю твои статьи.
Скрам-мастер не должен организовывать работу команды, он должен помочь команде самоорганизоваться.
Мне удалось вырабоать подход к декомпозиции работы, при котором оценки служат лишь инструментом проектирования, но не инструментом отвлечения программиста от работы и наказания за непопадание в них. Мне кажется, что мы нашли разумный баланс. Я описал этот подход в статье habr.com/ru/post/524678/#MercyfulDecomposition
Будет очень интересно узнать Ваше, nmivan, мнение и мнение читателей Вашей статьи.
Ключевой пункт, в котором мы с Вами расходимся, это отношение к закону Паркинсона.
Я считаю его неуместным в отношении креативной деятельности.
Когда возникает впечатление, что в конкретной ситуации закон сработал, то это нужно рассматривать как несчастный случай, а не закономерность. Я рассматриваю это как иллюзию.
В статье я более развернуто об этом пишу в разделе habr.com/ru/post/524678/#AboutBoundaries
После статьи есть голосование о законе Паркинсона.
Заранее благодарю за внимание!
Посадите программиста в поток. Защищайте. Не мешайте. Наслаждайтесь