Как стать автором
Обновить

Комментарии 213

Правильно. Оценки были в школе, пусть там и остаются.
НЛО прилетело и опубликовало эту надпись здесь
Так можно сказать что и школа не нужна. Какой еще есть способ мотивации школьников в условиях стандартизированной системы обучения?
Хотя аналогии между школой и разработкой ПО и неочевидны, можно пофантазировать на эту тему. Главное в школе что? Чтобы дети учились. Раньше их для этого пороли и ставили на горох. Сейчас родители гонят в школу. А что если сделать так, чтобы дети сами хотели туда ходить? И получать знания в интересной, увлекающей атмосфере? Может пора, наконец, редизайнить эту убогую систему образования? А? Но это так. Оффтопик.
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
Заинтересованность, я полагаю. Дети очень любопытны по своей природе. Проблема в том, что школа очень легко убивает любопытство у части детей. Уверен, что каждый имеет примеры того, как «плохой» педагог приводил к утрате интереса к изучаемой дисциплине. И обратные примеры любому тоже известны.
НЛО прилетело и опубликовало эту надпись здесь
Нет, я так не считаю (имел ввиду «если мыслить подобным образом, то можно дойти до того, что и школа не нужна»).
Насчет мотивации в частности и школы в общем — думаю, что необходима реорганизация, направленная на создание более индивидуального обучения. В зависимости от наклонностей человека будут различаться как предметы, так и способы мотивации. Как вариант — система стипендий/грантов для талантливых школьников (уже существует сейчас, но фактически не реглоаментирована законом и очень различается в отдельных регионах).
А мне думается, что для дополнения мотивации надо просто разрешить отличникам чмырить двоечников в коридорах. Вместо обратной ситуации, имеющей место сейчас.
Ну то есть достаточно в любой спорной ситуации принимать сторону того ученика, чья успеваемость выше.

Вот такая вот внезапно странная идея. Как вам?
В текущем виде школа действительно не нужна. Т. е. она, возможно, нужна государству, обществу или ещё кому-то, но не конкретному человеку, который в ней учится.
Временные затраты на обучение огромны, а багаж знаний, который ученик выносит в итоге — неоправданно мал.

Приведу пример: я готовил одну 11-классницу к ЕГЭ по математике. В процессе выяснилось, что за 10 лет её даже не научили, что такое дроби, и как их хотя бы складывать. Её учили правилам, формулам, чему угодно, только не пониманию. Нам с ней на то, чтобы разобраться в теме, потребовалась пара часов. Великим математиком девушке, конечно, не бывать, но я ей за месяц объяснил больше, чем школа за всё время.

Если говорить о системе оценок, то несколько лучше неё вариант с баллами: каждая работа оценивается в определённое число баллов, её можно пересдать, в итоге считается суммарный процент от всех баллов. Этот вариант не сильно лучше, но у него есть один большой плюс — ученик значительно меньше боится отвечать и писать работы: в худшем случае он получит мало баллов (что всё равно улучшит итоговый результат), а не двойку, которая его ухудшит. Система абсолютно рабочая, я когда-то по ней учился.

Но в целом нынешняя система образования делает всё, чтобы убить тягу к знаниям, и даже лучшим учителям сложно с ней бороться.

PS: Почитайте Кийосаки «Если хочешь быть богатым и счастливым, не ходи в школу», он несколько длинно, но понятно описывает, насколько ущербна образовательная система.
Мне тоже кажется, что репетитор для каждого школьника на 2 года — это эффективнее занятий в классе в течение 10 лет. Для ЕГЭ — точно. Но в классе как правило учатся ~30 учеников, так что в сумме это выйдет раза в 3-4 дороже.
А вместо школ начать активно развивать учреждения дополнительного образования с бесплатным обучением (такие как музыкальные, художественные школы, технические секции и компьютерные курсы).
Боюсь с пониманием плохо не только у учеников:

image

image
А что не так со вторым примером? Ну кроме того, что Маша очень быстрая.
мне кажется, что ученик подчинился трезвости ума
Согласен. В задании ясно написано, что Маша шла, а не бежала. :)
даже не так.
в задании НЕ сказано, что Маша _летела_
А она просто шла на ооооочень длинных ходулях :)
Ловкая такая Маша.
А ну-ка, кто здесь вычислит угловую скорость перемещения ног стандартного пешехода и затем определит минимальную необходимую длину Машиных ходулей?
Задача со звёздочкой:
Определить плотность материала из которого они должны быть сделаны, чтобы Маша таки могла их переставлять =)
на две звездочки: определите массу ходулей, чтобы ее мощности хватило их так быстро передвигать =)
на три звёздочки: назвать то, что курил автор задачи :)
Если считать что частота шагов одна и та же, то получается следующее:
18 м/с = 64,8 км/ч
Обычная скорость пешехода — 5 км/ч
Приняв длину ноги Маши равной 0,9 метрам, получаем что высота ходулей должна быть равна
0,9 * 64,8 / 5 = 11,7 метров
Википедия говорит нам что самые высокие ходули, с которых человек не наебнулся навернулся были высотой 17,2 метра. Так что все нормально :)
Run, Masha, run!
Молодец, Саша, садись — пять (т.е. плюс в карму) :)
А Вы, неучи, смотрите и учитесь…
Ну, кто готов заработать 5+ за звёздочки? :)))
парсер — лох, съел тэг irony
интересно, чему подчинялся автор это задачки :)
шустрая Маша — 64 км/час идти =)
Теплоход «Маша» идёт со скоростью…
а как они из ЧЕТНЫХ чисел получили НЕЧЕТНОЕ 41???
Это магия цифр.
42 — 2:2
теряем контекст?
вот из этих, пожалуйста:
12-6*14:2
Вы знаете, в этом, собственно, и шутка была.
НЛО прилетело и опубликовало эту надпись здесь
В разработке ПО оценивается время, причем наперед. А в школе — знания и постфактум. Так что аналогия некорректна: это два абсолютно разных значения слова «оценка».
Интересные мысли. Вот только мне кажется, что многие руководители не захотят использовать такую практику. Ход мыслей у них прост: если есть сроки (воспринимаеые как дедлайны, как Вы правильно заметили), то исполнители/ответственные лица боятся в них не уложиться, а значит делают «хоть что-то», чтобы успеть в сроки. Если отменить понятие «сроков», то люди могут вовсе перестать работать, особенно если есть проблемы с мотивацией.

Лично мне кажется, что вопрос очень непростой. И тут всё зависит от того, какие цели преследует руководитель. Если требуется обеспечить качество продукта или услуги, то согласен, что надо дать людям возможность хорошо (правильно) работать. Правда, упомянутая проблема с мотивацией может оказаться нерешаемой и тогда руководитель допустит ошибку, отказавшись от планирования и оценки объёмов работ. Но иногда боссам приходится ставить людям сроки из-за специфики работы или команды или внешних условий и т. д. В этом случае выбора нет.
Я не думаю, что дедлайны решают проблему мотивации. Если людей не прет от работы, то есть 2 варианта
1. они не очень профессионалы и сделают говно
2. они профессионалы и сделают нормально, но не более того

Постоянные дедлайны для обоих категорий будут давать следующее
1. непрофессионалы сделают больше говна за меньшее время
2. профессионалы сделают нормально, но хуже. И начнут просматривать объявления об интересной работе.
Однозначно «за». Просто не раз сталкивался с «совкового» типа руководителями. И моих возможностей убеждения оказывалось недостаточно для того, чтобы они перестали применять идею дедлайнов.

Из пяти компаний, в которых я работал, лишь в двух люди действительно могли работать свободно, без «пресса» времени. Мне трудно сказать, были ли люди в этих конторах сильно продуктивнее, но бьюсь об заклад, что они были намного счастивее.
Каким образом «дедлайны» связаны с «совком»?

>Мне трудно сказать, были ли люди в этих конторах сильно продуктивнее, но бьюсь об \
>заклад, что они были намного счастивее.
Заказчика это каким образом должно волновать?
Заказчика очень сильно волнует бабло.
Глупый заказчик будет думать что если подгонять разрабов, устанавливая дедлайны, требовать всего и сразу — то профита будет больше.
Хотя на самом деле с точностью до наоборот. Во время дедлайна даже очень хорошие разработчики пишут абы какой код — «чтобы работал»
после нескольких дедлайнов работа просто встанет — потому что запилить в систему новых фич станет уже невозможно из за того что старые фичи то и дело отваливаются и почти все время уходит на исправление багов в коде который был набросан в бессонную ночь перед очередным дедлайном зомби-разработчиком.
так что для заказчика самый правильный и самое главное экономически выгодный вариант — это когда разработчики делают свое дело спокойно и вдумчиво, чем как белка с гемороем пытаясь успеть к какой то временной отметке.
> разработчики делают свое дело спокойно и вдумчиво,
> чем как белка с гемороем пытаясь успеть к какой то временной отметке.
мне кажется мало кто из руководителей разработки, управляющий внешними клиентскими проектами может быть уверен в том, что его (пускай супер-лояльные) разработчики будут понимать «свое дело» так же как и он, а не читать хабр (в лучшем случае).
Да, вопрос непростой.

Если бы работу сотрудников оплачивали чем смогли надыбать, то песцовыми шкурками с консервированным супом, то антикварнами батами, то бесплатными походами ко врачу, хотя вряд ли руководство смогло бы общаться с сотрудниками в таком случае без страха, спокойно объясняя почему так получилось.

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

С другой стороны берем крупную компанию, уж методик менеджмента там обычно столько, что не продохнуть, оценивается каждый чих, а КПД, хоть о стену убейся, — низкий, король-то голый получается.
> а КПД, хоть о стену убейся, — низкий
не могу согласиться. злая корпоративная структура в какой-то мере — зло, но говорить о полной неэффективности управления в больших компаниях без примеров я бы не стал. вряд ли вы станете утверждать, что все крупные компании мира живут только за счет вливания денег (если не брать наши гос.корпорации :))
Как бы ни был хорош такой подход, его можно применить только при полном доверии к сотруднику, либо при использовании какого-либо другого метода оценки его труда.
Без доверия к сотруднику Agile ни в каком виде не даст нормальных результатов.
Млин, будьте милосердны. Я над вашей фразой чуть не сломал мозг, думая, кто же этот сотрудник Agile? Зпт.
Но ведь по правилам языка там не нужна запятая!
А зачем вам сотрудники, которым вы не можете доверять?
мне кажется, что набор команды с одинаковым восторгом относящейся к ЛЮБОМУ проекту, поступающему в компанию, задача маловыполнимая.
вот и оказывается руководитель, переходя от проекта к проекту, перед командой которой проект, к примеру, не интересен ваааще (соответственно доверять им работу без контроля — нельзя). и что, набирать на проект новую команду каждый раз?
Суть в непонимании реальной задачи дедлайнов.

Оценка конечно всегда крайне субъективна. Давит на команду. Дает боссу повод для наезда. И качество продукта почти всегда важнее соблюдения срока.

Но, временные ограничения фокусируют менеджера и команду на главном. Урежьте функционал, улучшите проектирование, сократите тесты, оставайтесь допоздна и т.д. Отведенное время=Бюджет проекта.

Вам захотелось бы тратить свои деньги на продукт неопределенно долгое время при постоянно растущих рисках?
Вы понимаете, что успех продукта, определяется не только качеством? Правильное время выпуска — очевидный фактор успешности.

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

я это делаю

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

я думаю, это очевидно. Успех определяется очень многими вещами, но в первую очередь реальной пользой от своего использования. Если польза есть, можно иметь в продукте баги и плохой перфоманс, и все равно он будет продаваться. Но проблема в том, что с дедлайном можно легко выплеснуть с водой и ребенка. Поставка будет вовремя, но урезанный функционал будет так себе, никаких wow не будет у конечных юзеров, и получится средний такой продукт. Выдающееся ПО требует времени.

Вообще статья не о дедлайнах, а об оценках. Хотя эти понятия и связаны, но это не одно и то же.

И еще. Есть большая разница, выпускаем мы первую версию продукта или десятую. Для первой версии можно много компромисов. Для десятой уже важнее качество.
Верно, версия продукта важна. Обычно основное wow дает первая версия, выпущенная своевременно. И такие продукты получают резиновый бюджет и поддержку. Управление становится более процессным, а не проектным. Значимость дедлайнов падает.

Думаю что задача проджекта — четко понимать, где ребенок, а где вода.

Главное в жизни это — не дедлайн, главное это — счастливые улыбки близких. Это для босса главным может быть дедлайн, а для людей поводом для гордости являются их дела. Хоть и сам об этом иногда забываю, но думайте о своей жизни, а не о чужих деньгах.
Это топик про оценки и деньги. Пускайте слюни в другом блоге.
Если можете работать классно-во время — улыбки и душевный покой вам :-)

Если нет — гореть вам в силиконовом аду!
Ну, у кого что болит… По мне, топик как раз про то, что не надо думать только о дедлайнах.
>Большинство людей по натуре оптимисты. Как подтвердили английские ученые, это встроенный атрибут. Поэтому большинство людей, даже очень опытных, дают чрезмерно оптимистичные оценки. За свою карьеру я ни разу не встречал программиста, который дает пессимистичные оценки. Может мне не везло и у вас есть такие.

Угу, приходит менеджер: «Нам уже вчера нужна новая фича, сделай ее за два дня».
Прикидываю, 2 дня — мало, говорю о двух неделях. В ответ: «Ты что, это же так долго, там же две строчки поменять нужно» (ага, а также переписать класс, изменить запросы и убедиться, что изменения ничего не сломали)
Менеджер уходит, возвращается с Самым Главным Начальником которому менеджер уже успел объяснить что на самом деле внедрение фичи — дело плёвое, это просто программист ленивый.
Поражает, что время на работу оценивает не тот, кто будет работать:)
Ну как бы да. Почему-то считается что все программисты это такие ленивые скотины которые никогда не хотят работать. :)
В этом-то имхо и проблема. Не все программисты «ленивые скотины», но и не все не «ленивые скотины»:) к тому же вопросы самоорганизации и самомотивации довольно сложны, не каждому подвластны.
Как можно отказываться от planning poker?
1. Процесс оценки позволяет найти быстрое и эффективное решение, если оно есть к кого-то в голове (он запускается, если оценки сильно разнятся).
2. Если не проставлять оценки, то долгие приоритетные задачи (новый функционал) будут постоянно перекрывать быстрые, но менее приоритетные (улучшение старого функционала). Без оценок придётся делить пул задач на несколько очередей.
3. Без обсуждения задач, проект рискует развалиться на подпроекты, когда каждый пилит часть, которая ему больше нравится и не знает, что происходит у остальных.
>Если не проставлять оценки, то долгие приоритетные задачи (новый функционал) будут постоянно перекрывать быстрые, но менее приоритетные (улучшение старого функционала

Ну… как бы… Если он более приоритетный, то так и надо? Нет?

>Без обсуждения задач, проект рискует развалиться на подпроекты

Какое, простите, это имеет отношение к оценкам? Что, нельзя собраться и обсудить задачу без ее оценки? Мы так и делаем. У нас перед каждой фичей обязательный митинг, где участвуют продукт оунер, тестер, девелопер и дизайнер. Он может быть очень короткий, на 15 минут. А может и на пару часов. Зависит от фичи.
>Ну… как бы… Если он более приоритетный, то так и надо? Нет?
Нет, тут как с разделением процессорного времени, низкоприоритетные задачи должны тоже получать ресурсы, только меньше. Но нет смысла выделять 1 час в неделю задаче, которая рассчитана на месяц, но при этом короткие задачи за 1 час могут закрыться.

>Какое, простите, это имеет отношение к оценкам?
Оценка — активный процесс. Можно долго слушать о фиче (во время daily-scrum, презентаций и т.д.) и не представлять о чём она, но при оценке придётся хотя бы чуть-чуть задуматься. И я говорил не про разные команды (тестер, девелопер и дизайнер), я говорил про одну однородную команду разработчиков.
> И я говорил не про разные команды (тестер, девелопер и дизайнер), я говорил про одну однородную команду разработчиков.

Ага, то есть у вас функциональные команды? Удачи тогда, что же еще остается пожелать.
Разве planning poker может существовать в разнородной команде?
Если у вас тестер оценивал сложность задач дизайнеров, то удививительно, что вы это пунктом 0 в статью не добавили.
Причем тут покер? В обсуждении фичи должны участвовать все, кто будет ее делать на ВСЕХ этапах. Кроме того, тут есть мноооого подводных камней в вашем подходе. А что, если тестирование очень сложное и долгое? А вы это не учтете? Или дизайнеру придется повозиться в 3 раза обычного времени, потому что IE6 надо поддержать, а он не знал? У вас только программисты делают задачи? Остальные так, баловством занимаются?
> Причем тут покер?

Мы же об оценках говорим.

> А что, если тестирование очень сложное и долгое? А вы это не учтете? Или дизайнеру придется повозиться в 3 раза обычного времени, потому что IE6 надо поддержать, а он не знал?

Вы меня не слышите, я говорю следующее: не так важен результат оценки, как процесс оценки. От того, что все ошибутся в оценке в 10 раз, трагедии не будет. Но чтобы у менеджмента было меньше соблазна использовать оценки для неадекватных претензий, придумали «пойнты».
Вы меня тоже не слышите. Я говорю следущее: не так важна оценка, как разговор о функциональности, который включает всех заинтересованных людей. То, что вы хотите выяснить при оценке, можно выяснить без нее.
То есть как? Назвать митинг «разговор о функциональности ...», приглашаются все, кто заинтересован или планирует когда-либо в будущем заинтересоваться?
По-моему, то что вы предлагаете — не является agile, т.к. структура не будет самоорганизующейся и кто-то должен будет всё продумывать заранее (кто, над чем работает), иначе всё развалится.
Для вас аджайл — это книжка сазерленда? Или книжка бека? Или книжка швабера? У меня создается впечатление (простите, если я не прав), что вы посетили кусры скрам мастера, почитали пару книжек и внедряете скрам полгода. Аджайл — это не скрам. Это не набор каких-то практик из книжек. Это парадигма.

Что надо продумывать заранее? Приведу конкретный пример из нашей компании. Я, продукт оунер, ставлю проблему «пользователи должны знать, что изменилось в новой версии». Собирается команда, включая меня, тестера, девелопера и дизайнера и мы вместе решаем, как это будет сделано. Тут обсуждается все, что надо для реализации фичи, включая тонкие моменты для тестирования и разработки. Это заняло ровно полчаса.

Что вы понимаете под самоорганизующейся структурой? Многие в скраме любят это слово, но понятия не имеют, что это такое.
> Что вы понимаете под самоорганизующейся структурой?
Если просто: если каждый участник команды неявно следует какой-либо процедуре, за ним никто не следит, но её не нарушит, потому что понимает, что это будет не правильно. Например: каждый разработчик команды понимает, что чекинить код без review, настолько же неприлично, как мочиться в лифте, за это не убьют, но не поймут.

> Собирается команда, включая меня, тестера, девелопера и дизайнера и мы вместе решаем, как это будет сделано.

С оунером можно решить, что будет сделано, а дальше девелоперы между собой, тестеры между собой, дизайнеры между собой должны решить, как это сделать. Как дать понять человеку, что он должен подумать над задачей, которую он скорее всего не будет делать? Но если сказать «необходима твоя оценка», то он поймёт и задумается.

P.S. Над вопросом «что для меня аджайл» я отвечать не хочу, т.к. аджайл не является для меня основной конфессией.
Обратимся к первоисточникам en.wikipedia.org/wiki/Self-organization

Self-organization is the process where a structure or pattern appears in a system without a central authority or external element imposing it through planning.

Неявное следование процедуре не является самоорганизацией. Главное — отсутствие решений сверху. Решения принимаются всей командой. Что в реальной жизни к сожалению встречается чрезвычайно редко.
Коммунизм не работает. Даже в статье написано не «Решения принимаются всей командой.», а «a system without a central authority» т.е. решает не команда, а каждый принимает решения для себя. Решения для команды принимаются командой. Решения, связанные с верхом принимаются сверху.

P.S. Забавный выбор первоисточника.
А разве без оценок и планирования Agile не превращается в чистой воды Cowboy Coding?
Оценки не имеют прямого отношения к планированию. В Scrum вы без оценок не сможете нормально добиться четких спринтов. Но спринты — это опционально. Можно и без итераций нормально жить, как это делают команды, работающий по Kanban.
я себе просто не могу представить планирования без оценок. как я могу сказать когда будет готова та или иная фича, если я не расчитываю производительность моей команды и оцениваю сложность этой фичи?
я по своему опыту знаю, что если перед разработчиками не ставить каких-то реалистичных сроков, а предложить всё планировать самим в течение процесса, то начинаются большие траты времени на левые дела, и затягивание сроков.
* не оцениваю
У меня в команде отсутствуют явные итерации и оценки (типа Kanban); могу сказать, что без них очень даже неплохо. Да, сложно прогнозировать дату очередного релиза, но точности от нас не требуют. Процесс простой — сначала максимальный scope down нового функционала + багфиксинг и менее приоритетные задачи. Если после этого остается какое-то время (т.е. не релиз может ждать) — то добавляем выкинутые фичи (сколько влезет) и релизим. А можем сразу зарелизить и перенести остатки в следующий релиз.
К сожалению, не всегда можно отказаться от оценок. К примеру, мы работаем на очень большую компанию, которая создает сложный продукт, состоящий из множества компонент. Соответственно, над каждой компонентой трудится несколько человек, количество варьируется от 5 до 20. Релизы должны создаваться строго по графику, который согласуется на самом высоком уровне. В каждой компоненте существует определенный набор функционала, который должен быть сделан, но упор делается на качество, поэтому можно пожертвовать несколькими фичами ради этого качества. Фичи нельзя просто так выкинуть, их тоже надо согласовывать. Поэтому, когда решается вопрос, что выкидывать, а что оставлять, то принимается во внимание важность (ценность) фичи, а также сложность (количество потраченного времени) и риски (можно что-то не учесть и время разработки может сильно увеличиться). Поэтому стараются для анализа исходить из разных факторов. Понятно, что для простых проектов это может быть совсем не актуально. Т.е. я хочу сказать, что все зависит от задачи и от множества разных факторов.
У вас есть точки интеграции — это хорошо. Есть зависимости между командами — это плохо, но я так понимаю сложно избежимо. В первую очередь можно подумать, как убрать эти зависимости. Тогда не очень важно с каким готовым функционалом придет команда к точке интеграции. Но нужно больше деталей, чтобы что-то конкретное обсуждать.
Зависимости есть, но они очень слабые. Дело не в зависимостях, а в том, что есть определенный срок, к которому все должны успеть. Потому как если какая-то команда скажет, что нам нужно еще месяцок, то это будет фатально для всего продукта, т.к. слишком много завязано на сроки: есть пользователи, есть ожидания, есть обязательства, есть вложенные деньги. Поэтому проще пожертвовать функционалом, чем увеличить время разработки, пусть и незначительно. В этом аспекте важно понять, какой функционал следует делать в первую очередь, а какой — перенести на следующий релиз или вообще не делать. И каждой решение — оно не простое, а выстраданное. Поэтому хочется сделать правильный выбор на основе большего количества данных.
А вообще, мне, как обычному программисту, проще работать без оценок. Т.к. любая оценка — это способ давления, как было уже сказано в статье. Оценки нужны менеджерам, а не программистам. Программисту нужна интересная задача и чтобы его никто не отвлекал. Все остальное ему до лампочки. Ну может еще чтоб получился хороший конечный продукт, за который бы он сказал: а я принимал участие для его создания!
Поправка :) в стиле грамма-наци: компонент (м.) — компоненты (мн.); компонентов, компонентом.
wiki:В соответствии с ГОСТ 34.003-90 данный термин имеет мужской род — Компонент.
Оценки важны не только для абсолютной оценки фичей, а скорее для относительной.
Чтобы заказчик — product owner — понимал, что вот эта фича в два раза дольше другой, а вот эта, наоборот, в полтора раза проще.
И соотносил это понимание с важностью той или иной штуки и менял приоритеты.

С учетом понимания между командой и заказчиком это весомый аргумент за оценки.

А к вопросу траты времени — это и не должно занимать много. Если не пытаться оценить с точностью до миллиметра и не спорить при малейших расхождениях. Оценка, к тому же, стимулирует к разбиению крупных задач и более четкому представлению о грядущем и о распределении тасков внутри команды.
> Чтобы заказчик — product owner — понимал, что вот эта фича в два раза дольше другой, а вот эта, наоборот, в полтора раза проще.

Согласен. Тем более, если оценка сделана в «зелёных попугаях», то как она может быть дедлайном для команды?
У нас частая ситуация, когда увидев оценку product owner отказывается от выполнения каких-то задач в пользу других, действительно важных.
Главная идея Agile: начальнеки и манагеры не мешайте людям работать :)

так что все эти покеры можно расценивать как промежуточный этап к тому что написал 9zloy
Непонятно как в такой системе отвечать на вопросы:«Когда это будет сделано?» — ведь это ключевой вопрос бизнеса и даже приблизительный ответ на него полезен.
Таким образом бизнесу будет сложно продать продукт или получить инвестирование не имея никаких ожиданий и оценок.
Я думаю без оценок можно, но тогда оценки должен давать кто то другой, например не исполнитель а менеджер который за ним наблюдает.
> Когда это будет сделано?

Ответ: когда будет готово. Если у бизнеса есть мнение, что есть более важные задачи, которыми надо заняться, то надо переключится на эти задачи.
Если таких задач нет, то, конечно, хочется знать, когда будет готово, но практика показывает, что пока готово не будет, сказать невозможно. В лучшем случае ошибки будут 20-30% по серьезной функциональности.

Roadmaps — это полезно. Но там такие оценки типа «ну вот примерно месяца через 3 эта функциональность может быть готова.» На деле оказывается, что через 6. Или через 8. Разбивать все на мелкие задачи и оценивать их? Хороший подход, если решение известно. Часто решение неизвестно, и нечего собственно оценивать.
Крайне рекомендую вам почитать «Черную книгу менеджера». Хорошо доводит доступным русским языком понимание нужд бизнеса.
Огромное спасибо за рекомендацию. Я сам руководитель бизнеса.
Не так страшна оценка как её малюють, главное — всегда поддерживать ее в актуальном состоянии.
Великолепная схема для разработчиков и полностью неприемлемая для нормального бизнеса.
Да ладно? Как же мы живем все эти годы… Мы уже два года не оцениваем работу. Положение вещей только улучшается.
«Оно улучшается» относительно чего? Улучшается ли оно по сравнению с теми, кто оценки все-таки делает? Заказчик внутренний? У заказчика много денег?
Относительно того, что было раньше. А раньше оценки у нас были. Мы — продуктовая компания без VC.
Я, в общем-то, рад за вашу команду ))) Но мне кажется, что дедлайны в индустрии встречаются очень часто (и не из-за капризов начальства, а по чисто внешним причинам — успеть к празднику, скажем), а планировать релизы без предварительных оценок — дело очень рискованное. То есть подавать отсутствие оценок как историю успеха я бы не стал.

Помимо этого, вы почему-то упираете на то, что анализ требований «отнимает время». Это достаточно спорно, можно, конечно, сэкономить на анализе, но потом это все равно выльется в мнократные потери при разработке. (хотя, наверное, для совсем простых систем можно наплевать и на аналитику)
>Помимо этого, вы почему-то упираете на то, что анализ требований «отнимает время».

Побойтесь бога. Я такого не говорил. Анализ требований совершенно необходим. Оценка — нет.
а вот это?
Тогда вы собираете данные, анализируете данные и обсуждаете результаты анализа. Все это тоже занимает прилично времени. Но подумайте, вам на самом деле нужны оценки? Часто это waste. Лучше потратить время на что-то действительно полезное для продукта.

Вырвано из контекста. Это касалось улучшения оценки :)
«А что, если вы хотите улучшить точность оценок?»
Уточнение оценки это и есть в большинстве случаев анализ, только «низкоуровневый». То есть фактически вы отказываетесь от учета рисков для сложных задач? Подозреваю, что именно поэтому у вас и проблемы с декомпозицией больших «кусков» работы.
Как разработчику мне комфортнее когда я знаю сроки. Тогда можно выделить время на работу и на безделье.
Если в вашей компании это работает и компания в финансовом смысле чувствует себя хорошо — то это хорошо)
Я даже Вам немного завидую.
Но всё же дедлайны иногда имеют объективную необходимость, например при запуске спутника на марс, срочной трансплантации, ну и датой начала массовой рекламной кампании)
Так уж складывается, что далеко не все из нас запускают спутники, срочно трансплантируют, да и, чего уж там, даже массово пускают рекламу. :)
Было бы здорово жить в таких реалиях, которые позволяли бы полностью отказаться от оценок вреени и объема задач, но чаще всего этого не позволяют требования бизнеса, окобенно при ведении клиентских проетов.

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

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

ИМХО такой подход возможен только для ресерч-групп в крупных компаниях, у которых достаточно диверсифицирован бизнес и достаточно ресурсов для обеспечения такого рода ведения работ.
> В этом случае от оценок отказаться практически невозможно так как ни один клиент не согласится на абстрактные сроки

Вы пробовали, или это просто ваше ИМХО? Многие компании успешно продают свои услуги без конкретных сроков.

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

Почти всегда, это сколько процентов? У нас нет никакого финансового плана. У многих успешных компаний его тоже нет. Есть стратегический план. Есть приоритеты. Сроков — нету.

> ИМХО такой подход возможен только для ресерч-групп в крупных компаниях, у которых достаточно диверсифицирован бизнес и достаточно ресурсов для обеспечения такого рода ведения работ.

Наша компания не относится к этой категории. Есть много других примеров, скажем, 37signals.
В нашей компании тоже обсуждали нужность/ненужность оценок. В итоге пришли к следующим пойнтам:

  • Задачи, которые можно оценить — нужно оценить. Но обычно это не большие задачи. Крупные задачи точно оценивать не умеет никто во всей отрасли разработки ПО.
  • Задачи, оценка которых затруднительна не оцениваются, либо оцениваются с очень крупной шкалой: квартал, полгода, год. Иными словами главное в оценке задчь честность.
  • Даже, если мы честно признаем, что не можем оценить задачу, заказчику легче не становится. Выход — еженедельные демо с обсуждением текущих подзадач и оценкой этих подзадач.
Вот еженедельное демо с тем, что выполнили — хороший способ говорить с заказчиком. Заказчику главное что? Ему главное, что есть хороший прогресс, что разрабатывается то, что ему надо, что разработчикам можно ДОВЕРЯТЬ. Если доверие удалось построить, все остальное не важно. И оценки ему не важны.
Заказчику обычно надо знать, сколько у команды займет времени реализовать то, что заказчик хочет (и соответственно — сколько это ему будет стоить). Расскажите пожалуйста, как работать с заказчиком не называя ему сроков и бюджета?
Я может быть невнимательно читал, но в любом из этих контрактов, кроме может быть Time and Materials, определяется Scope, а как можно подписаться на выполнение этого Scope не оценив его в человекочасах?
Вы опередили. Пока читал комменты, примерно тоже самое хотел изложить, только с примерами. Ну, да не буду повторятся — под ваши пункты, каждый может примерить свой опыт, и оценить, насколько успешно была решена задача в его случае.
Для отказа от оценок люди давно уже используют канбан.
Где вместо оценок в сторипоинтах используется система ограничений.
Вот, сразу видно, что товарищ в теме. +1
НЛО прилетело и опубликовало эту надпись здесь
Хорошие ответы и статья, но:

>> 1. Вы не будете тратить время на оценки

<irony>

А давайте не будем тратить время на юзабилити тестирование, рефакторинг и уборку постели утром перед уходом на работу :) Ведь за это время можно сделать что-нибудь действительно полезное для проекта!

</irony>

>> 2. Вам будет проще объяснять руководству, почему это было таааак дооолго

Отнюдь. Имея на руках разбивку фичи по частям с оценкой каждой из них, можно показать, что вот эти две вложились в сроки, а вот в этой возникли задержки из-за непредвиденных проблем в работе со сторонним API.

>>>> Если у вас есть оценки, руководство имеет соблазн прибегнуть к аргументу “что за фигня? Вы мне обещали сделать эту фичу к концу месяца!“

Да, соблазн есть, но как мне кажется, с ТАКИМ руководством без оценок будет еще сложнее: «что за фигня? Что можно делать уже ДВА месяца? Вы не могли сказать, что это будет НАСТОЛЬКО долго?!».

>> 3. Вы не даете обещаний, которые сложно выполнить

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

>>>> Более того, все равно в итоге вы будете иметь неточные оценки.

Если разработчик вовремя говорит о неудачности оценки и дает новую — такая точность лучше никакой. Даже в самом плохом случае, когда каждая переоценка фичи добавляет больше времени на разработку, чем прошлая, вы можете хотя бы понять, что что-то пошло не так.

>> 4. Вы не давите на команду

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

>>>>Для многих команд Оценка == Дедлайн.

Вы, по сути, не отказались от оценок, вы отказались от дедлайнов. При этом оценки отпали за ненадобностью.

>> 5. Вы фокусируетесь на важных вещах

>>>> Огромные фичи делать сложно и долго. Появляется большой соблазн сделать десяток фич поменьше.

Соблазны есть всегда, нужно просто их контролировать. Если вы понимаете, «что сейчас крайне важно», то вам будет безразлично, сколько эта важная фича «весит» в фичах поменьше. Вы просто возьметесь и будете делать — а как бонус вы будете примерно представлять, когда вы это закончите.

Ну а теперь немного вольных мыслей :)

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

Да ладно? Как же это мы выпустили первую версию продукта, без оценок? Видимо, это было чудо!
Мне не нравится эта зашоренность. Ты пробовал это применять в аутсорсе? При определенных условиях может сработать.

> Вы, по сути, не отказались от оценок, вы отказались от дедлайнов

Неверно. У нас никогда не было дедлайнов. А оценки были. Это разные вещи. Оценки — это дедлайны психологические. Общепринятое понятие дедлайна — это дата релиза.

> Опять-таки, можно было решить вашу проблему другим путем: помочь людям перестать воспринимать оценку как обещание и не чувствовать давления за отставание от нее.

Можно. А зачем, если оценки не нужны?
Основное правило скрама — жёсткий таймбоксинг.
Если нет планирования — то нет ограничений на итерацию.
Это уже скорее канбан, а не скрам.
Кто ж спорит. А ведь есть еще и такой зверь как Scrumban :)
>> Мне не нравится эта зашоренность.

Ну ладно, ладно, я же не полностью отказываюсь от такого варианта :) В конце концов, он работает, а это о многом говорит. В аутсорсе это может сработать, если заказчик похож на тебя — т.е. принимает такую неопределенность как должное. Если же версии продукта привязаны к бизнесу на «той стороне», то от оценок отказаться не получится.

>> У нас никогда не было дедлайнов. А оценки были. Это разные вещи.

А я и не говорю, что это одно и то же. Кстати, возможно, что от оценок вы отказались именно потому, что дедлайнов нету — в таком случае они действительно не особо нужны.

>> Можно. А зачем, если оценки не нужны?

:) Аргумент, но опять-таки только для ваших условий.
Что-то вы все в кучу смешали…
Оценки нужны, но на их основе нельзя строить мотивацию разработчиков. Оценки нужны для того, чтобы понимать, что происходит в проекте. Лучшая мотивация с которой я сталкивался: нормальная (по оценкам города) зарплата + премия если заказчик оказался доволен. Никто не рвет на себе рубашку, все спят по ночам, все думают о разработке. Ну да, еще вкусная столовка.
>Оценки нужны, но на их основе нельзя строить мотивацию разработчиков

Хмм. Где я такое написал? Оценки и мотивация — разные вещи.

5й номер крайне странный.
Только если PO поставил эквивалентное BV простым и сложным фичам. Иначе как можно ему объяснить что ценная для него фича не реализованна на протяжение нескольких итераций?
Все-же стоит уточнить область совета…

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

Для аутсорсинг компаний, с новым клиентом, который хочет протестировать подрядчика пробным fixed bid проектом, — «Impossible, мистер Карабасофф!». Да и вообще, fixed bid — корень зла ;) Но это миф, что можно убедить всех новых заказчиков сразу оплачиваемо верить новым отношениям.

Для поставки продукта, которому стратегически важна дата и есть внешние незыблимые временные рамки: WWDC для Apple, промо-сайт Coca-cola для London 2012, — тоже «Impossible, мистер Карабасофф!».

и т.д.
У любой системы есть ограничения. С вашим комментом — согласен.
Если говорить о юриспруденции, то я так не люблю оценки в это сфере. Расценки типа «час работы юриста» и «договор делается за 4-6 часов» на меня наводят ужас. Когда я работаю над договором, то у меня в голове крутится мысль не о качестве договора, а о количестве часов, которые я на него потратил и как я объясню клиенту, что часов пришлось потратить больше. Аналогично и по другим проектам.
Договариваетесь вы с заказчиком о работе.
Он говорит: «Оккей, вижу вы ребята толковые. Сколько вам нужно времени что сделать эту работу?».

Ваши действия?
Очень приближенно можно так
«Мы делали подобные проекты, обычно это занимает около 2 месяцев, но мы предлагаем другое. Каждую неделю мы будем показывать, что было закончено, и вместе будем решать, над чем работать дальше. Вы можете в любой момент отказаться от проекта на текущей его стадии. Так вы будете уверенны, что мы делаем действительно нужные для вас вещи»

Вообще эта тема не новая. Тут например собранна хорошая пачка примеров решения проблемы

alistair.cockburn.us/Agile+contracts
agilesoftwaredevelopment.com/blog/peterstev/10-agile-contracts
Таким образом вы выбираете только тех заказчиков, которые согласны работать по agile'овской схеме?
Наша компания делает свой продукт. Я никогда не работал на заказ по аджайл схемам. Но. Не вижу ничего плохого в том, что компания выбирает себе клиентов. Лет 15 назад это казалось бы дикостью. Сейчас работать с заказчиком по гибкому контракту уже можно пробовать.
Не думаю что это реалистично чтобы компании (в среднем) начали выбирать себе клиентов.
Особенно компании, которые занимаются разработкой, скажем, не сайтиков, а медицинского оборудования или любого другого специфического софта.

Я всегда думал что команда по большей части подстраивается под заказчика.

p.s.
> Наша компания делает свой продукт. Я никогда не работал на заказ по аджайл схемам.
В таком случае думаю вам стоит указать это в посте. Иначе весь текст теряет смысл.
> В таком случае думаю вам стоит указать это в посте. Иначе весь текст теряет смысл.

Нет, не теряет. Не вижу принципиальных причин, почему это не может работать для других компаний. Ограничения есть? Да. Но иногда полезно смотреть на проблему радикально и задумываться, можно ли это сделать. Только так можно придумать что-то (извините за избитое слово) инновационное. Вы уверены, что это не сработает в аутсорсе? Я — нет.
Уверен. Все что описано выше — отношения уровня «менеджер-команда».
Мнением и потребностями бизнеса тут не пахнет. IT в бизнесе — это сервис.
Пример.
Абстрактная ситуация, которая проецируется на большое число проектов для бизнеса:
Живет компания. Затеяли реорганизацию, направленную на оптимизацию бизнес-процессов. К концу реорганизации (due time) нужна новая erp-система. Ищут подрядчика. Приходят к вам.
Ваши действия?
> К концу реорганизации (due time) нужна новая erp-система

Это пример из области сферического коня в вакууме. Я уверен на 100%, что реорганизация не случится к намеченному сроку. Это не тот процесс, который имеет четкий конец. Соответственно, ERP система если и будет сделана, то будет иметь кучу серьезных недочетов, или вообще неверных бизнес процессов. Все, что можно сделать, плотно работать с руководством компании, чтобы как можно раньше сделать как можно больше (и то, что нужно). Дедлайны тут не помогут.
Это вы на основе какой информации, простите, додумали?
Интуиция. Меня легко переубедить. Опишите мне реальный пример подобной реорганизации. И я вам поверю, что это возможно.
Имеется отдел у заказчика (20 человек). Документооборот.
Было: 20 человек заключают договора и их обслуживают (принимают корреспонденции по ним, рассылают, организуют документооборот и т.д.). Каждый из них имеет свою коллекцию договоров и таким образом выполняют всю положенную работу по договорам из своего набора («от» и «до»).

Желание заказчика: разделить работу так, чтобы конкретные сотрудники занимались только часть работы (одна часть занимается заключением договоров, вторая часть — их обслуживанием, третья — организацией переметки, четвертая — закрытием).

Таким образом желание бизнеса состоит в том, чтобы работа по договорам стала более операционной (какой она собственно и должна быть).

Бизнес-процесс понятен. Проблем с реализацией бизнес-логики нет.

Заказчик во время реорганизации отдела проводит частичное переформирование штата, обучение сотрудников, переезд в новое здание и т.д.

Бинго. Переубедили. В данном случае дедлайн неизбежен. Есть и другие исключения, когда он неизбежен — крупная выставка для игры. Ниже есть еще примеры. В этом конкретном случае оценка потребуется, чтобы хотя бы понять, сколько примерно людей надо, чтобы успеть до дедлайна (если есть возможность менять количество людей).

Однако есть много ситуаций, когда все не так жестко.

Я не настаиваю, что оценки всегда и везде нужно упразднить. Просто надо задумываться, нужны ли они на самом деле в каждом конкретном случае.
Проблема в том что я настаиваю на том что осмысленных оценок должно быть как можно больше. Разумеется до того момента как следующая оценка может быть получена из линейной оболочки предыдущих.
Еще два вопроса.

1. Какого размера у вас команды и какого масштабы проекты? (Просто кажется я начал догадываться к какой классификации по книжке «мифический человеко-месяц» вы относитесь. Хочу проверить).

2. Всяческие отчетности и метрические показатели при правильном использовании по ходу развития большого проекта помогают существенно оптимизировать процесс разработки. Как вы обходитесь без них?
1. www.targetprocess.com — я не знаю, что вы имеет ввиду под масштабом. Хорошая книжка, кстати.

2. Легко. Очень абстрактный вопрос. Уточните.

1. Сколько человек у вас в команде (сколько программистов, сколько тестеров, сколько аналитиков и т.д.)?

2. Каким образом вы оцениваете эффективность своей команды? И если вы ее не оцениваете, то как вы узнаете что ваша команда работает на все сто процентов, на которые она может?
1. 30 человек. 10 программистов.

2. Никаких метрических оценок нет. Как это ни печально, в разработке софта прямых оценок эффективности не существует. Есть косвенные, но они малополезны.

>вы узнаете что ваша команда работает на все сто процентов, на которые она может?

А что такое 100%? Мы берем на работу только профессиональных разработчиков. У нас нет слабых программистов вообще. Средний опыт — около 7 лет. Мы создаем все условия, чтобы им было работать приятно. Команда сама улучшает свой рабочий процесс. Мы исходим из того, что профессионалы, которых интересует их дело, стремятся к совершенствованию.

Некоторые метрики помогают обнаружить проблемы в процессе, это так. Для нас это Lead/Cycle Time и баги из продакшена. Но это довольно общие метрики, которые только сигнализируют о наличии проблемы. В чем она конкретно заключается, можно определить только анализом.

А как вы узнаете, что ваша команда работает на 100%? Мне очень интересно, как метрики вам помогают это делать.
1. Ну т.е. у вас маленькая команда, в которой в принципе можно вообще нормально жить без какой-либо методологии, а так же можно жить с любой из методологии. Тем более когда разрабатываете свой продукт.
Не запутались ли вы в предположении что модифицировав стандартные методы разработки, вы получили прирост в производительности команды? Тем более что вы эту самую производительность никак не измеряете и не можете твердо сказать какой она была и какой стала?

2.
>У нас нет слабых программистов вообще
Как это связано с тем хорошо они работают в команде или нет?

>А как вы узнаете, что ваша команда работает на 100%?
>Мне очень интересно, как метрики вам помогают это делать.
В конкретных ситуациях по-разному.
К примеру, ведется проект. Есть два отдельные группы разработчиков: первая — развивает функционал, вторая — латает выявленные дефекты.
По накопленной статистике видно что количество выявляемых ошибок растет быстрее чем количество исправляемых. Отсюда делаем вывод что надо усиливать вторую команду засчет первой.
Производительность Команды увеличивается.
> Ну т.е. у вас маленькая команда, в которой в принципе можно вообще нормально жить без какой-либо методологии

Вы уверены, что 150 человек нельзя разбить на 10 маленьких команд?

>К примеру, ведется проект. Есть два отдельные группы разработчиков: первая — развивает функционал, вторая — латает выявленные дефекты.

Я очень, искренне сочувствую этому проекту. Особенно я сочувствую второй группе разработчиков. Почему-то мне кажется, что это гос. проект. Нет? В нормальном бизнесе такое еще бывает?
>Вы уверены, что 150 человек нельзя разбить на 10 маленьких команд?
Вы правда читали «мифический человеко-месяц»? И как это относится к поставленному вопросу?

> Я очень, искренне сочувствую этому проекту.
> Особенно я сочувствую второй группе разработчиков.
> Почему-то мне кажется, что это гос. проект.
> Нет? В нормальном бизнесе такое еще бывает?
Нет. И собственно это был пример того как метрики помагают. Мне больше интересно как бы поступили вы без метрик в данном случае.

p.s. вы не отвечаете на главные вопросы и смысл диалога теряется:
>У нас нет слабых программистов вообще
Как это связано с тем хорошо они работают в команде или нет?
> И как это относится к поставленному вопросу?

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

> Мне больше интересно как бы поступили вы без метрик в данном случае.

Я бы убрал это идиотское разделение на две команды. Если метрик нет, то есть количество жалоб от клиентов. Значит надо фиксить качество. Я бы ввел автоматические тесты (если их еще нет) и не выпускал бы фичи, без хорошего тестирования. Баг в продакшене — это должно быть редкостью, а не нормальным положением вещей. Ну это тема уже другого разговора. Я к тому, что если что-то становится важным, тогда этим и надо заниматься. А момент, когда что-то становится важным, часто виден и без метрик.

>Как это связано с тем хорошо они работают в команде или нет?

Это связано с эффективностью. Слабые программисты — неэффективны. Самый просто способ повысить эффективность — брать на работу сильных программистов.
>>Как это связано с тем хорошо они работают в команде или нет?
>Это связано с эффективностью. Слабые программисты —
> неэффективны. Самый просто способ повысить эффективность —
> брать на работу сильных программистов.

Простите. Я думаю наши взгляды слишком сильно разнятся. Я больше привык к тому что говорят Ашматов, Орлов, Брукс, Архипенков. Вы же видимо слишком революционны, отвергая все их идеи на корню.
Более того, мне нравятся их методы и советы, которые вы прямым текстом называете идиотскими.
Ну и также я доверяю своему опыту работы с заказчиком, который полностью совпадает с описанным выше и полностью разнится с вашим.

Поэтому извините — дальше не вижу смысла в этой дискуссии. У нас слишком разные базисные понятия.

Успехов.
Если вы не согласны с тем, что «Самый просто способ повысить эффективность — брать на работу сильных программистов.» то пожалуй да, нам вряд ли есть о чем поговорить.
Какова стоимость добавления программистов в середине проекта? А в конце?
Ответ очевиден. И что? Если вы намекаете на то, что добавлять в конце проекта программистов — плохо, а есть другие способы увеличить эффективность, то это возможно. Но. Есть исключения. Если вы добавити в конце проекта ОЧЕНЬ классных программистов, то есть шанс, что они его вытянут. А если любых других, то все будет по Бруксу.
Вы управляете очень-очень маленькой командой, которая развивает небольшой функционалу проект. Да еще и вебовский.

И почему-то экстраполируете свои знания на всю прочую разработку.

p.s. у вас есть хотя бы один программист, который выигрывал всероссийские олимпиады по программированию/математике? С топкодера может призеры есть? Что такое «очень» классные программисты?
Нет, я не занимаюсь экстраполяцией. И конечно этот подход нельзя применить везде (кажется, я уже это говорил раза 3). Если брать, скажем, космическую индустрию или сложные инженерные системы с по, то он не покатит. Не надо за меня додумывать.

Но большинство людей делают бизнес-софт. И для многих проектов в бизнес-софте можно не делать эстимейтов. Для больших продуктов можно не делать эстимейтов. Для разработки на заказ это гораздо сложнее, то тоже есть кейсы когда возможно.
Скажем по-другому, ваш проект (я про указанный сайт) имеет очень простую бизнес-логику (что в принципе и правильно: простой инструмент — простая логика).

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

p.s. у вас есть хотя бы один программист, который выигрывал всероссийские олимпиады по программированию/математике? С топкодера может призеры есть? Что такое «очень» классные программисты?
>Покажите мне проект со средней или сложной бизнес-логикой, реализованный вами с использованием ваших методов.

Что вы подразумеваете под «Нашими методами»? Scrum, Kanban? XP? Agile?

Наша компания в Минске. Какие всеросийские олимпиады? Призеры наших олимпиад есть, да. Мы не twitter и не facebook, нам не нужны генетические алгоритмы и erlang. Все верно, у нас достаточно простая система. У нас свои критерии подбора людей и они достаточно жесткие. К примеру, из 20 людей на собеседованиях за последние месяцы мы взяли 2. Подробнее о нашей компании можно узнать очень быстро
taucraft.com/dev/
1.
>>Покажите мне проект со средней или сложной бизнес-логикой,
>>реализованный вами с использованием ваших методов.
>Что вы подразумеваете под «Нашими методами»? Scrum, Kanban? XP? Agile?
То что описано в посте.

Таким образом остается вопрос о вашем проекте, который сложнее калькулятора и при создании которого вы опирались на те принципы, которые указаны в посте.

2. По ссылке абсолютно бесполезная информация о квадратных метрах.
Опишите вашу команду. Что значит «очень классные» программисты? Создается впечатление что вы принимаете за таких программистов, которые умеют писать код.
По ссылке есть полезная картинка нашего рабочего процесса.

Более подробно

habrahabr.ru/company/taucraft/blog/112854/

www.targetprocess.com/blog/2009/10/our-development-process.html

> Создается впечатление что вы принимаете за таких программистов, которые умеют писать код.

Поправка. Программистов, которые умеют писать КЛАССНЫЙ код, а точнее, придумывать и реализовывать классные решения.
Господи. Ну скажите уже какой у вас самый «крутой программист». Ну не томите. Чем он особенный? Что он придумал? Почему его надо захедхантить?

Я вообще не понимаю как вы умудряетесь определить что программист такой «КЛАССНЫЙ» на задачах вроде вашей, которые интеллектуальных усилий требуют очень мало.
Господи. Ну скажите уже какой у вас самый «крутой программист». Ну не томите. Чем он особенный? Что он придумал? Почему его надо захедхантить?

Я вообще не понимаю как вы умудряетесь определить что программист такой «КЛАССНЫЙ» на задачах вроде вашей, которые интеллектуальных усилий требуют очень мало.
А кто такие Ашматов, Орлов и Архипенков? Я знаю Кобурна, Бека, Швабера и Де Марко.
Предлагаю погуглить.
Погуглил. Это они?

ru-ru.facebook.com/people/%D0%81%D0%B4%D0%B3%D0%BE%D1%80%D0%B1%D0%B5%D0%BA-%D0%90%D1%88%D0%BC%D0%B0%D1%82%D0%BE%D0%B2/100000740493797

ru.wikipedia.org/wiki/%D0%9E%D1%80%D0%BB%D0%BE%D0%B2,_%D0%93%D1%80%D0%B8%D0%B3%D0%BE%D1%80%D0%B8%D0%B9_%D0%93%D1%80%D0%B8%D0%B3%D0%BE%D1%80%D1%8C%D0%B5%D0%B2%D0%B8%D1%87

www.arkhipenkov.ru/

Как не странно, у вас проблемы с использованием гугла.
Кстати, Архипенков мне понравился. Ознакомлюсь поглубже. Спасибо за наводку. Особенно мне понравился вот такой слайд

«Разработка продукта длилась 5 лет, вместо 1 года. Бюджет превышен более чем в 5 раз. Провал? Нет. Это был MS Word»

Не чувствуете, какое это имеет отношение к нашей дискуссии?
Ах да, у вас видимо опечатка. Вы наверное имели ввиду АшмаНова?
Лекции Архипенкова морально устарели
docs.google.com/viewer?url=http%3A%2F%2Fwww.arkhipenkov.ru%2Fresources%2Fsw_project_management.pdf

Их нельзя читать студентам. Только в формате исторической ретроспекции.
У вас видимо совсем где-то зашкалило, если вы книгу, которая по содержанию сильно pmbok (4 ed.) напоминает, называете морально устаревшей.
PMBOK в своей бОльшей части неприменим для разработки софта. Это же касается диаграмм Гантта (за редким исключением родмэпов и релизов), вотерфола (за редким исключением повторяемых проектов) и прочего хлама.
Вот это круто.
И откуда у вас такие светлые мысли?

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

Лет 7-8 назад я обратил свое внимание на альтеративные подходы к управлению проектами, именно по той причине, что вотерфол и PMBOK были очень сильно оторваны от реальности разработки ПО. Там конечно есть полезные вещи, процентов 20.
Вы делаете мне смешно.

Ответьте мне еще на два вопроса:
1. в чем принципиальное отличие таких вещей как pmbok и таких вещей как agile, scrum и т.д?
2. а если у меня получается планировать на три месяца вперед, с постоянными корректировками — уже не будете восхищаться?
Я рад, что вы улыбаетесь. Это же здорово!

1. сколько времени у вас уходит на корректировки?
2. Для какого уровня планирования вы используете гантт чарт?
3. У вас есть там задачи с конкретным исполнителем, оценненые в часах (днях)?
1. Корректировки планов? Отразить их в дневнике проекта? Даже и не знаю… Наверное минут 5.

2. Расписание задач по аналитикам/программистам, а так же их взаимосвязь.

3. Конечно есть.
Это печально. А сколько человек у вас в проекте?
И чем это печально?
Скажите, сколько у вас человек, тогда я смогу пояснить. Я честно отвечал на все вопросы о нашем контексте. Жду от вас того же.
Так все же, сколько у вас человек на проекте?
НЛО прилетело и опубликовало эту надпись здесь
Подход хорош, если проект делается для себя. Подход совершенно не подходит, если проект делается для стороннего заказчика.
Поправка.

Подход хорош, если проект:
1. Маленький
2. Делается маленькой командой
3. Делается для себя
Это скорее уточнение. Согласен.
А также может сработать в некоторых других случаях, которые пока не проверены практикой.
Например, крупная продуктовая компания может теоретически не оценивать работу.
Вы не сможете доказать, что это не так, пока не попробуете.
Эм. Тут как бы логика совсем другая:
«Модель не работает пока не доказано обратного».
Вы же почему-то априори решили что модель работает, пока не доказано что она не работает — чушь и бред.

P.S. да интересно с чего бы крупной продуктовой компании не оценивать работу? У них главное — правильная логистика, а это оценки, оценки, планы, оценки, планы, планы и еще раз оценки. И тут вдруг такая компания должна отказаться от оценок. Чушь не говорите.
>Вы же почему-то априори решили что модель работает, пока не доказано что она не работает — чушь и бред.

Я это не решал. Это видимо вы решили. Я утверждаю, что на МОЖЕТ работать.

Вы вообще способны выйти за стереотипы крупной компании, существующей сейчас? Или вы только и можете долбить прописные истины? Как вы думаете, Google сильно заботиться о логистике разрабатывая Gmail? Как вы думаете, оценивали ли они Wave (он загнулся, но вряд ли по этой причине)? Это все проекты, выросшие из Labs. Как же это случилось, не будучи запланированным и оцененным? Длань господня опустилась на чело руководителей гугл и привела их к инновационным решениям?
1.
>Я это не решал. Это видимо вы решили. Я утверждаю, что на МОЖЕТ работать.
Вы, надеюсь, понимаете что ваше «МОЖЕТ работать» — это пока лишь тупое желание нескольких человек. На практике это не проверено, а значит смысл этих знаний/предсказаний находится около нуля. Вы не согласны?

2.
>Это все проекты, выросшие из Labs. Как же это случилось, не будучи
>запланированным и оцененным?
Вот это уже вранье. Предоставьте доказательства того что при разработке этих проектов не использовались оценки.

3.
>Длань господня опустилась на чело руководителей гугл и привела их к инновационным решениям?
Какое вообще все описанное выше относится к инновациям? Вы уже мягкое с теплым путать начинаете.
1 МОЖЕТ работать — это гипотеза. Гипотезы полезны, нет?

2 Я мог бы посоветовать вам погуглить, но сделал это за вас

«there aren't Gantt charts or date-task-owner spreadsheets or any other visible project-management artifacts in evidence, not that I've ever seen.»

«The difference is that Google isn't foolish enough or presumptuous enough to claim to know how long stuff should take. So the only company-wide dates I'm ever aware of are the ends of each quarter, because everyone's scrambling to get on that big launch screen and get the applause and gifts and bonuses and team trips and all the other good that comes of launching things with big impact at Google.»

steve-yegge.blogspot.com/2006/09/good-agile-bad-agile_27.html
1. Абсолютно безосновательные гипотезы бесполезны.
2. Ну ао-первых, в написанном же сказано что раз вквартал оценки были, а во-вторых сказано что не было оценок, связанных с датами вех и релизов. Как отсюда следует что оценок не было в принципе?
Так как я вижу что ваше понимание понятия оценок в управлении проектами отличается от того что я принял считать нормой вопрос:
3. Что для вас оценка?
Пару вопросов:
1. Сколько сотен тысяч строк кода в вашем софте? (это о сложности вопрос)
2. Сколько проживет ваша компания без продаж? (это вопрос о сроках и бюджетах)
3. Как вы обойдетесь без оценок если вам нужно выполнить работу в срок, за фиксированный бюджет и с нужным результатом? (это риторический вопрос, ответа не требует)

А насчет точности оценок — посмотрите FogBugz и подход Джоэла Спольски к планированию и оценке времени.
Не можете поставить оценку = не понимаете, что именно делаете и как.

Кстати, о «не функциональной команде» (подсмотрел в комментах выше): А что это у вас на сайте вакансии висят на джаваскриптера, на дотнетчика, тестера? Так и писали бы — нанимаем 5 человек на должность члена трудового коллектива (у меня на одной из прошлых работ был коллега на такой должности). И перекидываете задачи между ними.
мне одному показалось, что в статье намеренно упущен тег [irony]?
я лично ждал в каментах 5 причин, почему надо отказаться от отладки, профилировки, юнит-тестирования и комментариев
1) отладка продукта — это лишнее время. даже написание слова ASSERT — это несколько совершенно лишних нажатий по клавишам, которые можно заменить чем-то другим
2) без профилировщика вы и так знаете какие части работают быстро, а какие медленно, даже если многомегабайтный проект попал вам вчера от уволившегося сотрудника
3) баги пусть ловят специально обученные тестеры, программисты пусть тратят время на креатив
4) важность задачи совершенно не зависит от ее сложности. гораздо лучше год работать над одной действииельно важной фичей, чем за три для сделать сто улучшений о которых так просят пользователи и манагеры
5) ну и так далее
Видимо везет Вам с заказчиками, я так понимаю они к Вам приходят, дают ТЗ или что-то подобное и говорят: «Ребята, когда сделаете проект, позвоните, чтобы запускаться начали», как можно без оценок работать?

Как Вы планируете итерации? или у Вас просто огромный пул задач, и релиз каждые N-недель? если нет, то значит какая-то оценка происходит, раз Вы набиваете итерацию.
У них нет заказчиков.
Неясно, как к такой схеме прикрутить мотивацию сотрудников. Иными словами, премии/бонусы?

У меня возникала идея отказаться от сроков совсем, оценивать задачи в деньгах, которые получит разработчик(команда) по завершению. Соответственно, есть мотив сделать побыстрее чтобы приступить к следующей. С другой стороны, если поспешил и сделал криво — вынужден тратить время на баги, которые никакими бонусами не оплачиваются.

Никто не пробовал такую схему? Она совершенно не принимается менеджерами, т.к. они привыкли мыслить сроками.
Скорее всего не пройдет такая схема т.к. менеджер не может сказать заказчику когда будет сдан проект, ну поставьте себя на место менеджера и говорите заказчику: «Проект будет стоить 10000 рублей, но когда мы его выкатим никто не знает», да и мотиватор разработчиков слабоватый, договорился менеджер на 10000 рублей приходит к программистам и дает ТЗ со словами «за него вы получите 9000 рублей», а ребята смотрят и понимают, что там работы на полгода, и работать как-то не хочется в команде из 3-х человек.

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

>>за него вы получите 9000 рублей», а ребята смотрят и понимают, что там работы на полгода, и работать как-то не хочется в команде из 3-х человек.

И правильно не хочется, если менеджер не может нормально оценить стоимость — значит плохой менеджер, уходить от него надо.

Эту схему я придумал для расчета премиальной части оплаты сотрудников, занимающихся разработкой долгоживущих коробочных проектов. Правда руководству схема не очень понравилась. Она имеет недостатки, да.
Если для премий то можно предложить такие варианты:

1. Сделали разработчики все вовремя ЗП * Повышающий коэффициент
2. Сделали разработчики больше чем планировали ЗП * (Повышающий коэффициент * 2)

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

Идеально конечно смотреть по ситуации.

Также можно предложить некую бонусную систему, скажем за квартал. Не по 300 долларов ежемесячно, а раз в три месяца 900-1000, но опять же по результатам работы. И довольны все и ничего страшного, если где-то не вложились в сроки, всегда можно нагнать.
Спасибо, подумаем. Проблема усугубляется еще тем, что в процессе заняты как минмум два отдела: разработки и тестирования. Если ставить им срок общий — попадать будут всегда тестировщики, т.к. они в конце производственного процесса. Как ставить отдельные сроки — не ясно, т.к. после первого этапа кодинга начинается совместная работа.
Оценки нужны для составления бюджета проекта. Если заказчик готов оплачивать потраченные часы по факту — его дело, тогда есть еще о чем поспорить. Да и то, команду синхронизировать надо в рамках задач каждого, одна фича быстрее вырастет, чем другая например. Самое паршивое в проектах — это удивляться.

И более того. Если внимательно посмотреть на диаграмму Гантта (это там, где оценки), иногда можно ускорить проект раза так в два. Но agile диаграмма Гантта не нужна, я знаю.
Я не к тому, что Agile — это нехорошо. Это по-другому.

P.S. А тэг канбан к чему тут?
Отказаться от оценок в итеративной разработке практически невозможно, потому что велосити и предсказуемость итераций должна быть. В канбане нет итераций, поэтому становится в принципе возможно отказаться от оценок.
>>Оценки нужны для составления бюджета проекта. Если заказчик готов оплачивать потраченные часы по факту

Мне кажется «время» — лишняя промежуточная оценка. Почему бы сразу в деньгах не оценить?
Ну у Заказчика на ПО свои задачи завязаны, это раз.
Пожалуй, самое главное, что в процессе разработки используется время программистов и других специалистов, которое нужно оплачивать. И это время денег стоит. Вот смотрите, программист за месяц может поучаствовать в 1,2,3… проектах (не только разработкой, но и поддержкой, и так далее). Как разносить затраты по проектам? По часам.

Оценки «по аналогии» (разработка такого продукта может стоить «столько-то») неточны. Нет базы для совершенствования разработки и управления проектами в компании. Неизвестно, окупится ли мероприятие, или нет. А когда есть детальная разбивка по задачам, заметно снижаются и риски. Известно, что суммарная ошибка оценки падает при детализации как корень из N.

ИМХО, ИТ уже не та отрасль, в которой сверхдоходы крутятся. Всё больше становится, гм, промышленной что ли. Поэтому и подход к выполнению заказов — проектный, а в проектном деле оценка снизу-вверх (сроков, затрат, рисков, качества и др.) давно уже оправдывает себя.

Если совсем кратко, то оценка сроков нужна чтобы не облажаться по деньгам.
Согласен, если есть заказчик, договор и срок.

Но ведь такой схемой не ограничивается разработка ПО.
Есть массовый коробочный софт, который почему-то всегда обходят стороной в подобных статьях. Там нет заказчика, как такового. (можно считать заказчиком какого-то менеджера, но ИМХО это притягивание за уши). Сроки придумывает руководство

PS: давно вынашиваю идею написать статью про особенности разработки такого софта по собственному богатому опыту, информации в сети катастрофически мало
Наверное не открою секрет, что такие проекты — инвестиционные. В них вкладываются, чтобы получить отдачу. И тут сроки важны по следующим причинам — конкуренция, опять же сроки — это деньги исполнителям, опять же сроки — это насколько исполнители будут заняты проектом А (а не другим важным Б или В), и наконец сроки — это сколько времени пройдет до начала положительных денежных потоков по проекту (время начала которых влияет на такой показатель как NPV).

А статью напишите, будет интересно почитать. Свои продукты — это всегда интересней чем заказ.
Есть такое понятие как bootstrapping. Это значит развитие без инвестиций. Наша компания не имеет внешних инвестиций. Это совершенно другой подход к развитию, накладывающий необычные ограничения. Это слишком далеко от корпораций и больших компаний, чтобы разговаривать на одном языке. И да. Я понимаю, что bootstrapping применим не всегда.
не хотите статью о своем опыте написать? очень интересно
С точки зрения финансового менеджмента, без разницы кто вкладывается и чем. Все инвестиции должны отбиваться, NPV применим и к фирме, не только кредиторы его считают. Стоимость твиттера в миллиард во времена до первых денег с него — это и есть тот самый NPV. Вполне вероятно, что ваш стартап имеет ненулевую стоимость (NPV), зависит от… наверное напишу статью…
А блин, написал, а кармы не хватает. ((
инвестиционные они только на старте. Потом такие проекты могут жить годами. Сам в таком участвую уже 8й год. Когда пришел, он уже приносил прибыль. Тем не менее мотивация сотрудников все равно нужна.
Написал статью, кармы опубликовать не хватает. Поэтому просто дам ссылку на свою позицию, т.к. она длиннее, чем это возможно изложить в комментариях. Я в курсе что блоготу (да я и сам не люблю, о чем можно убедиться по ссылке) тут не любят, но и файл я тоже не могу прикрепить :)
Почитал, неплохая статья, но не хватает циферок на мой вззгляд и упрощенных понятных примеров. Типа «Вася делает сайт за рубль, два тратим на рекламу а через год имеем четыре».

И раздел «Это всё какие-то финансы! Где agile, rup и etc?» не раскрывает ничего к сожалению. Общие слова, что все это тоже оценивается, бюжетируется, что и так всем понятно
ОК, уже правлю, прямо по живому :)
> Для многих команд Оценка == Дедлайн. Это ужасно.

Для многих бизнесов Cрыв Cроков == Потери. Это ужасно.
В конце концов бизнес выберет предсказуемость. То есть команду, которая хорошо знает свою производительность. Agile появился как раз для того, чтобы внести предсказуемость в процесс разработки.

Нужно уходить от «Оценка == Дедлайн», это задача для менджера/тимлида.

> 1000 поинтов — это много. Фича огромная. Огромные фичи делать сложно и долго.

Конечно. Такие фичи нужно дробить на более мелкие части. По правде говоря, ее нужно начать дробить, еще не доходя до оценки 1000 поинтов. Фиксированный набор оценок служит этой цели. У вас ведь нет карточки «1000».

> Если вы не оцениваете, вы просто начинаете работу над тем, что сейчас крайне важно.

Чтобы owner мог решить, что сейчас важнее всего, ему нужно знать в том числе и оценку, а не только свои желания. Это все равно, что в магазине выбирать между сыром и колбасой, не глядя на цену (а в кармане 100 рублей). Вы же вынуждаете его принимать решение с неполной информацией. Это противоречит целям Agile.
>Чтобы owner мог решить, что сейчас важнее всего, ему нужно знать в том числе и оценку, а не только свои желания.

Не всегда. Иногда достаточно желаний и оооочень общего представления, сколько это может занять.

> Нужно уходить от «Оценка == Дедлайн», это задача для менджера/тимлида.

Это возможный вариант. При условии, что оценки есть :)

>Конечно. Такие фичи нужно дробить на более мелкие части

Это и ежику понятно, что такие фичи надо дробить на мелкие. Это не решает проблемы, потому что все равно общая фича огромна. Но согласен, что этот аргумент самый слабый. Потому что часто от кусочка фичи можно тоже можно получить бенефиты. Но не всегда.
К сожалению разработчики не любят говорить о сроках, но любят получать зарплату в срок.
Если учитывать, что
  1. Разработчики достаточно профессиональны и хорошо мотивированы
  2. Есть доверие между заказчиком и исполнителем (или это работа над собственным продуктом)
тогда описанный подход может дать хороший результат с минимумом затрат на побочную деятельность.
В комментариях часто прослеживаются вопросы — «а если разработчики то..., а если это...». Да, если разработчики не опытны, не понимают что и зачем они делают или не хотят сами это сделать — то да, нужно пасти. В другом случае — достаточно периодически корректировать и не мешать.
Как всегда — сколько людей, столько и мнений. Добавлю свои две копейки.

1. Вы не будете тратить время на оценки

Сильно зависит от того как вы занимаетесь оценкой задач/фич. По опыту
могу сказать, что на это уходит не так уж много времени. Больше уходит
на выяснение «а что имелось в виду под требованием Х?», деталей задач и т.п.

Без оценки хотя бы в попугаях более-менее эффективно можно делать только
очень простые проекты (примерно до 3-4 календарных месяцев, команда до 10-15 человек).
При этом сами исполнители все равно делают оценки сроков «для себя».

2. Вам будет проще объяснять руководству, почему это было таааак дооолго

Есть различия в оценках (estimates), заявленных сроках выполнения работы (commitments)
и целях (goals). Если нет понимания, чем эти вещи отличаются принципиально, то можно
долго говорить ни о чем. Могу рекомендовать эту книгу прочитать:
Software Estimation: Demystifying the Black Art

Задача менеджера проекта как раз и состоит в том, чтобы commitments были близки
к целям, которые ставит руководство. Редко когда бывает, что оценки совпадают
с целями. А если цели неадекватные, то тут могут быть варианты.

Если сроки поехали, а хороший менеджер проекта знает об этом заранее, то надо
говорить с руководством об этом. Если в компании нормальным является фраза:
«что за фигня? Вы мне обещали сделать эту фичу к концу месяца!», то это мягко
говоря «смерть» менеджеру проекта и/или исполнителям. В общем, сильно нездоровая
обстановка, когда люди боятся говорить про оценки и риски. у ДеМарко есть
хорошая книга на эту тему: Slack.

3. Вы не даете обещаний, которые сложно выполнить
По оценке хороший материал я привел выше. Конечно, в бардаке и хаосе,
зачастую называемыми модными терминами типа Scrum, Kanban и т.п. (без обид),
никакие оценки не помогут, т.к. оценка — это вспомогательный инструмент
при управлении проектами

4. Вы не давите на команду
Тема мотивации бездонна, иногда нужно и надавить. Тут еще в контексте
затрагивается вопрос качества, это отдельная тема для разговора. Кто-то
ссылался на PMBOK, вполне хороший теоретический материал, можно почитать
про «классический треугольник» с качеством в одном углу и как «управлять»
проектом, используя метафору треугольника

5. Вы фокусируетесь на важных вещах

— «Если вы не оцениваете, вы просто начинаете работу над тем, что сейчас крайне важно. Это просто.»
А как определить, что делать в первую очередь? Если по принципу «просто берем и делаем», то может получится так:image
Могу лишь сказать, что проблема не в оценках, а в отношении к ним. Мы не рассматриваем оценки как что-то настоящее — это просто способ оценить относительный прогресс.
Зарегистрируйтесь на Хабре , чтобы оставить комментарий