Комментарии 59
НЛО прилетело и опубликовало эту надпись здесь
Даже в сложных проектах, таких, как софт, можно набросать прототип, эскизный вариант за короткое время. Пусть это даже неделя — вместо месяца. Пусть там говнокод, который потом все равно будет переписан.
Смысл в наибольшем рывке на первом этапе в ущерб качеству, за счет скорости, чтобы максимальное количество раз проитерировать и в кратчайший срок попасть как можно ближе к нужному на деле результату.
Это, разумеется, не нужно, когда уже заранее известны все детали, как и что нужно сделать, и для чего. Но даже в таких проектах все равно бывают ошибки — 100% понять, что будет делать живая система, можно понять только на живых данных и в боевых условиях. Грубый пример — если брать дизайнеров и заставлять их рисовать не с красивыми левыми текстами, а РЕАЛЬНЫМИ надписями, вы гораздо быстрее увидите косяки в логике самого макета (нежели когда сверстали, закодили, а потом клиент добавил 20 пунктов меню и все криво). Еще пример — если у вас поисковый механизм по набору данных, и вы, радостно его погоняв на паре записей «тест» «бла бла бла», сдаете клиент, который ругается потом на тормознутость поиска (Не были учтены моменты, что данные у него в реальности имеют какие-то особенности).
Быстрый прототип с подстановкой живых данных и работой с заказчиком — тупо хороший способ снизить издержки на коренную переработку. Когда прошли считанные дни с разработки, говнокод не жалко переписать. Когда ваши программеры делали месяц два фильтра, они будут с ними очень тяжело расставаться, даже если клиент уже перехотел эти фильтры. Да и систем будет тяжелее, ее переработка — дороже.
Смысл в наибольшем рывке на первом этапе в ущерб качеству, за счет скорости, чтобы максимальное количество раз проитерировать и в кратчайший срок попасть как можно ближе к нужному на деле результату.
Это, разумеется, не нужно, когда уже заранее известны все детали, как и что нужно сделать, и для чего. Но даже в таких проектах все равно бывают ошибки — 100% понять, что будет делать живая система, можно понять только на живых данных и в боевых условиях. Грубый пример — если брать дизайнеров и заставлять их рисовать не с красивыми левыми текстами, а РЕАЛЬНЫМИ надписями, вы гораздо быстрее увидите косяки в логике самого макета (нежели когда сверстали, закодили, а потом клиент добавил 20 пунктов меню и все криво). Еще пример — если у вас поисковый механизм по набору данных, и вы, радостно его погоняв на паре записей «тест» «бла бла бла», сдаете клиент, который ругается потом на тормознутость поиска (Не были учтены моменты, что данные у него в реальности имеют какие-то особенности).
Быстрый прототип с подстановкой живых данных и работой с заказчиком — тупо хороший способ снизить издержки на коренную переработку. Когда прошли считанные дни с разработки, говнокод не жалко переписать. Когда ваши программеры делали месяц два фильтра, они будут с ними очень тяжело расставаться, даже если клиент уже перехотел эти фильтры. Да и систем будет тяжелее, ее переработка — дороже.
Даже в сложных проектах, таких, как софт, можно набросать прототип, эскизный вариант за короткое время. Пусть это даже неделя — вместо месяца. Пусть там говнокод, который потом все равно будет переписан.
Смысл в наибольшем рывке на первом этапе в ущерб качеству, за счет скорости, чтобы максимальное количество раз проитерировать и в кратчайший срок попасть как можно ближе к нужному на деле результату.
Это, разумеется, не нужно, когда уже заранее известны все детали, как и что нужно сделать, и для чего. Но даже в таких проектах все равно бывают ошибки — 100% понять, что будет делать живая система, можно понять только на живых данных и в боевых условиях. Грубый пример — если брать дизайнеров и заставлять их рисовать не с красивыми левыми текстами, а РЕАЛЬНЫМИ надписями, вы гораздо быстрее увидите косяки в логике самого макета (нежели когда сверстали, закодили, а потом клиент добавил 20 пунктов меню и все криво). Еще пример — если у вас поисковый механизм по набору данных, и вы, радостно его погоняв на паре записей «тест» «бла бла бла», сдаете клиент, который ругается потом на тормознутость поиска (Не были учтены моменты, что данные у него в реальности имеют какие-то особенности).
Быстрый прототип с подстановкой живых данных и работой с заказчиком — еще хороший способ снизить издержки на переработку под изменения в дальшейшем. Когда прошли считанные дни с разработки, говнокод не жалко переписать. Когда ваши программеры делали месяц два фильтра, они будут с ними очень тяжело расставаться, даже если клиент уже перехотел эти фильтры. Да и систем будет тяжелее, ее переработка — дороже.
Смысл в наибольшем рывке на первом этапе в ущерб качеству, за счет скорости, чтобы максимальное количество раз проитерировать и в кратчайший срок попасть как можно ближе к нужному на деле результату.
Это, разумеется, не нужно, когда уже заранее известны все детали, как и что нужно сделать, и для чего. Но даже в таких проектах все равно бывают ошибки — 100% понять, что будет делать живая система, можно понять только на живых данных и в боевых условиях. Грубый пример — если брать дизайнеров и заставлять их рисовать не с красивыми левыми текстами, а РЕАЛЬНЫМИ надписями, вы гораздо быстрее увидите косяки в логике самого макета (нежели когда сверстали, закодили, а потом клиент добавил 20 пунктов меню и все криво). Еще пример — если у вас поисковый механизм по набору данных, и вы, радостно его погоняв на паре записей «тест» «бла бла бла», сдаете клиент, который ругается потом на тормознутость поиска (Не были учтены моменты, что данные у него в реальности имеют какие-то особенности).
Быстрый прототип с подстановкой живых данных и работой с заказчиком — еще хороший способ снизить издержки на переработку под изменения в дальшейшем. Когда прошли считанные дни с разработки, говнокод не жалко переписать. Когда ваши программеры делали месяц два фильтра, они будут с ними очень тяжело расставаться, даже если клиент уже перехотел эти фильтры. Да и систем будет тяжелее, ее переработка — дороже.
А разве что-то вообще реально довести до конца?
Что-то серьезное?
Что-то серьезное?
Для начала скажем, что слово «до конца» — часто субъективное ощущение. Клиент понимает по-своему, вы по-своему. Хорошо бы это понимание синхронизировать, сначала на уровне мышления, затем на уровне договора.
И, выделив некую стадию, после которой проект объективно можно запускать, считать достижение этой стадии — доведением до конца. Грубо говоря, сделали магазин и через него уже можно продавать — вот это доведение до конца. Но да, клиент хочет уже сразу и лучшие товары дня на главную, и спецакции вывести — но нужно, чтобы клиент понимал — это уже доработки, допилка самодостаточного проекта, а не минимальное необходимые работы по проекту, чтобы проект тупо взлетел.
И, выделив некую стадию, после которой проект объективно можно запускать, считать достижение этой стадии — доведением до конца. Грубо говоря, сделали магазин и через него уже можно продавать — вот это доведение до конца. Но да, клиент хочет уже сразу и лучшие товары дня на главную, и спецакции вывести — но нужно, чтобы клиент понимал — это уже доработки, допилка самодостаточного проекта, а не минимальное необходимые работы по проекту, чтобы проект тупо взлетел.
т.е. в вашем понимании запуск == доведение конца?
Это мне кажется не верным. Вот мы запустили проект пол года назад уже как, но его настолько перелопатили за эти пол года… Совсем не тянет на «доведение до конца». У действительно хороших продуктов нет конца — они очень долго поддерживаются и развиваются… ну а интернет магазины… ну их тысячи и это заказная работа, скажем так, а с ними и так в 90% случаев понятно когда конец, а вот реальные проекты… тут уже хрен знает что…
Это мне кажется не верным. Вот мы запустили проект пол года назад уже как, но его настолько перелопатили за эти пол года… Совсем не тянет на «доведение до конца». У действительно хороших продуктов нет конца — они очень долго поддерживаются и развиваются… ну а интернет магазины… ну их тысячи и это заказная работа, скажем так, а с ними и так в 90% случаев понятно когда конец, а вот реальные проекты… тут уже хрен знает что…
Доведение до конца = доведение до конечного результата.
Это ясно, что хорошие проекты поддерживаются нередко в течение многих лет.
Весь вопрос в том, чтобы четко выделить первый этап — собственно, рождение проекта и его оживление, и затем допилку. Если эти стадии не разделить — будет долгострой, который часто клиенту не нужен, потому что время ушло. И плюс на каждой стадии своя специфика работы — я бы даже сказал, очень разная
Это ясно, что хорошие проекты поддерживаются нередко в течение многих лет.
Весь вопрос в том, чтобы четко выделить первый этап — собственно, рождение проекта и его оживление, и затем допилку. Если эти стадии не разделить — будет долгострой, который часто клиенту не нужен, потому что время ушло. И плюс на каждой стадии своя специфика работы — я бы даже сказал, очень разная
Это по сути обычная приоритезация задач.
1. выделяем группу очень важных задач, которые должны быть выполнены к дедлайну.
2. делаем их.
3. формируем новый блок задач и новый дедлай, если еще есть задачи и коммерческая необходимость в них
4. завершаем проект, когда все готово, либо оставляем его просто на поддержке меньшим ресурсом.
1. выделяем группу очень важных задач, которые должны быть выполнены к дедлайну.
2. делаем их.
3. формируем новый блок задач и новый дедлай, если еще есть задачи и коммерческая необходимость в них
4. завершаем проект, когда все готово, либо оставляем его просто на поддержке меньшим ресурсом.
по поводу проектов — можно выделить стадию самодостаточности.
грубо говоря, вот если вы запустите проект и оставите его на год, а он проработает — значит, это конечный результат. да, он может быть криво написанным, неудобным, еще что-то, но будет решать главные задачи.
если же проект не взлетает, не работает, не решает своих задач — самодостаточность еще не достигнута.
затем стадия логической связности. весь функционал логичен, все элементы интерфейса логичны.
потом — визуальный тюнинг. уже можно вешать рюшечки, заниматься аудитом юзабилити, и так далее.
грубо говоря, вот если вы запустите проект и оставите его на год, а он проработает — значит, это конечный результат. да, он может быть криво написанным, неудобным, еще что-то, но будет решать главные задачи.
если же проект не взлетает, не работает, не решает своих задач — самодостаточность еще не достигнута.
затем стадия логической связности. весь функционал логичен, все элементы интерфейса логичны.
потом — визуальный тюнинг. уже можно вешать рюшечки, заниматься аудитом юзабилити, и так далее.
Здесь тоже вопрос очень спорный. потому что «проект решает свои задачи» принципиально разные состояния для заказчика (пользователя) и разработчика. Здесь как раз и начинается «пляска» с интерфесами (клиент хочет не просто результата 0 или 1, а нечно красиво оформленное, прогнанное через юзабилити).
Я бы предложить рассматривать этапы готовности как минимум с двух точек зрения — т.з. разработки и т.з. приемки (клиента).
Я бы предложить рассматривать этапы готовности как минимум с двух точек зрения — т.з. разработки и т.з. приемки (клиента).
Наверное надо различать доведение до конца работы по ТЗ от «третьих лиц» и разработка «собственных» проектов, которые неизвестно куда повернут в своем развитии.
ТЗ либо выполнено, либо не выполнено.
ТЗ либо выполнено, либо не выполнено.
Соотношение 80/20 называется принципом Паретто. Думаю 90/10 можно отнести туда же.
Вспомнился демотиватор в тему
>Когда менеджер из примера наберется опыта, он сможет укладываться в месяц, если будет говорить команде, что за две недели максимум нужно сдать проект.
Потом команда просечёт фишку и будет автоматически умножать всё, что говорит манагер, на 2.
Потом команда просечёт фишку и будет автоматически умножать всё, что говорит манагер, на 2.
…
— Вы знаете, нам нужны кирпичи!.. — начала разговор Галя.
— Сколько? — поинтересовался Иван Иванович, продолжая писать.
— Много, — торопливо вставил Чебурашка. — Очень много.
— Нет, — ответил Иван Иванович, — много я дать не могу. Могу дать только половину.
— А почему?
— У меня такое правило, — объяснил начальник, — всё делать наполовину.
— А почему у вас такое правило, — спросил Чебурашка.
— Очень просто, — сказал Иван Иванович. — Если я всё буду делать до конца и всем всё разрешать, то про меня скажут, что я слишком добрый и каждый у меня делает, что хочет. А если я ничего не буду делать и никому ничего не разрешать, то про меня скажут, что бездельник и всем только мешаю. А так про меня никто ничего плохого не скажет. Понятно?
— Понятно, — согласились посетители.
— Так сколько кирпичей вам нужно?
— Мы хотели построить два маленьких домика, — схитрил крокодил.
— Ну что ж, — сказал Иван Иванович, — я вам дам кирпичи на один маленький домик. Это будет как раз тысяча штук. Идёт?
…
Кстати, подход раш + допиливание хорошо работает и в больших проектах. Причем стадия активной разработки может длиться 2-3 недели. Дольше сложно т.к. это сильно истощает команду. Плюс нужно быть готовым к тому, что велосити последующих итераций может оказаться существенно ниже обычной.
Единственное, я бы не стал жертвовать качеством — это обычно не окупается даже в среднесрочной перспективе.
Единственное, я бы не стал жертвовать качеством — это обычно не окупается даже в среднесрочной перспективе.
>С другой стороны, пришел и за час сделал модуль, просчитанный на день — гуляй. За сутки нарисовал макетов на три дня вперед — возьми два отгула
Такого не бывает. Даже если каким-то чудом попасть работать в контору, где тебе правда это пообещают (и даже буду выполнять), менеджер очень быстро просечёт твою производительность и будет нагружать тебя на 100-120%.
Такого не бывает. Даже если каким-то чудом попасть работать в контору, где тебе правда это пообещают (и даже буду выполнять), менеджер очень быстро просечёт твою производительность и будет нагружать тебя на 100-120%.
Какая-то утопическая статья. Ни один проект не нужно доводить до конца, если только это не конец проекта. Звучит странно, но реальность показывает как раз именно такую закономерность.
Теперь пояснение, почему это так. На мелких проектах используется самая дешевая рабочая сила, чтобы проект хоть как-то окупался. Соответственно качества исполнения ждать не приходится. Огрехи будут всегда, недочеты будут всегда. На средних проектах доводить до конца становится вредно, потому что на доделку оставшихся 20% фич вам понадобится 80% времени. Ибо рефакторинг вас забодает вусмерть. На крупных проектах против доделывания начинает играть время. Пока вы будете думать над завершением функциональности, она уже устареет и отомрет. Т.е. вы еще не придумали как вы будете это делать, еще не приступали к разработке, а это уже не нужно.
Кроме экономической целесообразности еще важно понимать психологию клиента. Если все хорошо и продукт выполняет 100% задач клиента, вы просто банально не нужны. Зачем платить за поддержку, если на данный момент времени в ней нет необходимости? Подумать о будущих проблемах заказчик не хочет, и когда у него потребуется что-то доделать, вы скорее всего уже не сможете выполнить его доработки по старой цене, так как сейчас вы заняты другими проектами, и вам не очень оправдано тратить силы на более дешевые вещи. После разрыва договорных отношений очень редко они восстанавливаются снова.
Теперь пояснение, почему это так. На мелких проектах используется самая дешевая рабочая сила, чтобы проект хоть как-то окупался. Соответственно качества исполнения ждать не приходится. Огрехи будут всегда, недочеты будут всегда. На средних проектах доводить до конца становится вредно, потому что на доделку оставшихся 20% фич вам понадобится 80% времени. Ибо рефакторинг вас забодает вусмерть. На крупных проектах против доделывания начинает играть время. Пока вы будете думать над завершением функциональности, она уже устареет и отомрет. Т.е. вы еще не придумали как вы будете это делать, еще не приступали к разработке, а это уже не нужно.
Кроме экономической целесообразности еще важно понимать психологию клиента. Если все хорошо и продукт выполняет 100% задач клиента, вы просто банально не нужны. Зачем платить за поддержку, если на данный момент времени в ней нет необходимости? Подумать о будущих проблемах заказчик не хочет, и когда у него потребуется что-то доделать, вы скорее всего уже не сможете выполнить его доработки по старой цене, так как сейчас вы заняты другими проектами, и вам не очень оправдано тратить силы на более дешевые вещи. После разрыва договорных отношений очень редко они восстанавливаются снова.
Пока не показал макет — не ушел с работы
Что за рабовладельческий строй? Не относитесь к работникам как к рабам, ибо они отплатят вам той же монетой. Я каждый вечер пинаю народ, чтобы они шли домой и не засиживались. Потому что усталость имеет свойство накапливаться, и эффективность от переработок не позитивная, а негативная. Был у меня пример такого экстремального забоя. Всего 4 часа ночью проработали, а потом два дня на работу ходили зомби. Вопрос, что я выиграл? Ничего.
смысл не в том, чтобы относиться к работникам, как к рабам.
смысл в том, чтобы людям показать — здесь и сейчас нужен результат, а не просиживание штанов.
за редким исключением, во многих областях можно показывать результат в конце дня.
а если просто человек ЧУТь-ЧУТЬ не дорисовал, не исправил небольшой баг — он часто и завтрашний день повторяет то же самое, но с другой задачей.
блин, ко мне приходит человек, говорит — хочу 50,000 рублей (без опыта работы причем), место, макбук, хуюк, кофе, обеды и мальчика, чтобы обмахивал от солнца и мух разгонял.
я не готов с ним работать.
а если приходит молодой, способный, глаза горят — окей. сначала с меньшей ЗП начинаем, но человек каждый день доводит задачи до конца, до результата. идут месяц, второй, год -и человек сам видит, что он растет. благодаря практике результативности, практике малых побед.
итак, я не говорю, что это должно быть всегда. но навыки работать не просто планомерно в течение хотя бы недели, а выдать результат именно сейчас, не после 19:00 забить хрен и уйти, а добить, задержавшись до 9, а затем спокойно завтра прийти позже (Или уйти раньше)
смысл в том, чтобы людям показать — здесь и сейчас нужен результат, а не просиживание штанов.
за редким исключением, во многих областях можно показывать результат в конце дня.
а если просто человек ЧУТь-ЧУТЬ не дорисовал, не исправил небольшой баг — он часто и завтрашний день повторяет то же самое, но с другой задачей.
блин, ко мне приходит человек, говорит — хочу 50,000 рублей (без опыта работы причем), место, макбук, хуюк, кофе, обеды и мальчика, чтобы обмахивал от солнца и мух разгонял.
я не готов с ним работать.
а если приходит молодой, способный, глаза горят — окей. сначала с меньшей ЗП начинаем, но человек каждый день доводит задачи до конца, до результата. идут месяц, второй, год -и человек сам видит, что он растет. благодаря практике результативности, практике малых побед.
итак, я не говорю, что это должно быть всегда. но навыки работать не просто планомерно в течение хотя бы недели, а выдать результат именно сейчас, не после 19:00 забить хрен и уйти, а добить, задержавшись до 9, а затем спокойно завтра прийти позже (Или уйти раньше)
надо было мне обновить страницу перед отправлением ))
Чтобы в коллективе ориентироваться на результат, нужно просто напросто на собственном примере показывать, что вот так надо делать правильно. Через время, ваша высокая планка будет примером для подражания. Все подтянутся к ней.
Никакое стимулирование кнутом не сделает из разгильдяя педанта (не путать с людьми нетрадиционной сексуальной ориентации). Зачем вы ставите человека в жесткие рамки? Он быстрее или качественнее работать не будет. Постоянное психологическое давление доводит человека или до состояния раба, или до нервного срыва с последующим увольнением. Конечно, для многих предпринимателей первый тип людей очень выгоден.
Как бороться с мелкими недоделками? А создавайте тикеты человеку на все недоработки. Через время, глядя на полотенца тикетов, ему или станет стыдно за свое разгильдяйство и он подтянется, или же он поймет, что причина в нем. Если человек неисправим, с ним лучше всего расстаться.
Никакое стимулирование кнутом не сделает из разгильдяя педанта (не путать с людьми нетрадиционной сексуальной ориентации). Зачем вы ставите человека в жесткие рамки? Он быстрее или качественнее работать не будет. Постоянное психологическое давление доводит человека или до состояния раба, или до нервного срыва с последующим увольнением. Конечно, для многих предпринимателей первый тип людей очень выгоден.
Как бороться с мелкими недоделками? А создавайте тикеты человеку на все недоработки. Через время, глядя на полотенца тикетов, ему или станет стыдно за свое разгильдяйство и он подтянется, или же он поймет, что причина в нем. Если человек неисправим, с ним лучше всего расстаться.
я убежден, что умение работать на результат — то, чему можно научить, но самому научиться сложно.
подавать пример — очень заразная привычка. разумеется, без этого нельзя, но кто сказал, что сотрудники не будут думать — ну вот пусть и работает за всех :) ясное дело, это решается контролем, но весь вопрос в деталях.
если человек знает, что с него не просто спросят отчет, а попросят показать результат, вполне себе четкий, а не пару строк в workflow системе — он мыслит иначе.
ясно, это стрессовый режим. так как не всегда бывает вдохновение, и так далее.
но вот давайте будем честными. тут все знают про GTD, про правило бить задачи крупные на мелкие. почему в работе не помогать людям развивать в себе эти навыки? и людям саморазвитие, и делу польза.
подавать пример — очень заразная привычка. разумеется, без этого нельзя, но кто сказал, что сотрудники не будут думать — ну вот пусть и работает за всех :) ясное дело, это решается контролем, но весь вопрос в деталях.
если человек знает, что с него не просто спросят отчет, а попросят показать результат, вполне себе четкий, а не пару строк в workflow системе — он мыслит иначе.
ясно, это стрессовый режим. так как не всегда бывает вдохновение, и так далее.
но вот давайте будем честными. тут все знают про GTD, про правило бить задачи крупные на мелкие. почему в работе не помогать людям развивать в себе эти навыки? и людям саморазвитие, и делу польза.
Умение работать на результат приходит с пониманием экономической эффективности.
Подавать пример нужно, иначе возникает диспропорция в субординации. Работник будет считать как минимум подлецом того менеджера, который с других требует, а сам не делает.
Вы что, серьезно полагаете, что ужесточив рабочую дисциплину вы сможете научить человека правильно организовывать свое время? Скажу вам по секрету, человек сделает все, чтобы успевать в срок, но это будет сделано совершенно не так, как вы предполагаете. Например, создав ответный трафик писем со словами: «А не могли бы вы мне пояснить поподробнее, что имелось в виду под ...», работник получит снижение единовременной нагрузки, а в целом это приведет к тому, что вся система будет работать менее эффективно.
Подавать пример нужно, иначе возникает диспропорция в субординации. Работник будет считать как минимум подлецом того менеджера, который с других требует, а сам не делает.
Вы что, серьезно полагаете, что ужесточив рабочую дисциплину вы сможете научить человека правильно организовывать свое время? Скажу вам по секрету, человек сделает все, чтобы успевать в срок, но это будет сделано совершенно не так, как вы предполагаете. Например, создав ответный трафик писем со словами: «А не могли бы вы мне пояснить поподробнее, что имелось в виду под ...», работник получит снижение единовременной нагрузки, а в целом это приведет к тому, что вся система будет работать менее эффективно.
Думается, автор говорил про мотивацию сотрудников, речь про то, чтобы оплата была завязана на результат, в данном случае автор просто поменял данные ресурсы местами: деньги <-> время. Что сути, в общем, не меняет.
Дело в том, что пока ты дописываешь «до конца», я имею в виду программистов, которые пишут не на контору, а для себя, то пока ты дойдешь до этого победного конца, в голове перебазируется еще столько идей, как переписать тот или иной модуль, что очень тяжело сказать, где же будет та финишная прямая, на которой можно или даже нужно остановиться.
Как сказал Стив Джобс, Real artists ship. Так что конечно доводить до конца нужно обязательно (ну или убедиться, что доводить до конца не нужно совсем :)
Мне кажется, Continuous Delivery понимается не совсем верно автором. В оригинале это поставка после каждого коммита. Закоммитил код — собрался и протестировался готовый билд, который можно ставить на продакшн. Это сложно, дорого, но достижимо.
Но в статье есть гораздо более тяжелый минус — оплата, ориентированная на результат. Мы вступаем на тонкую почву эстимейтов, в которых программеру очень легко ошибиться. За результат легко платить, когда табуретки делаешь, когда создаешь систему — это практически нереально. Эстимейты ВСЕГДА будут ошибочными. И это ведет к попыткам сделать эстимейты побольше, чтобы подстраховаться. А заказчик будет просить поменьше, чтобы поменьше заплатить. Это ведет к политическим играм и всему остальному неприглядному грязному белью. Ну его нафиг.
Мне кажется, Continuous Delivery понимается не совсем верно автором. В оригинале это поставка после каждого коммита. Закоммитил код — собрался и протестировался готовый билд, который можно ставить на продакшн. Это сложно, дорого, но достижимо.
Но в статье есть гораздо более тяжелый минус — оплата, ориентированная на результат. Мы вступаем на тонкую почву эстимейтов, в которых программеру очень легко ошибиться. За результат легко платить, когда табуретки делаешь, когда создаешь систему — это практически нереально. Эстимейты ВСЕГДА будут ошибочными. И это ведет к попыткам сделать эстимейты побольше, чтобы подстраховаться. А заказчик будет просить поменьше, чтобы поменьше заплатить. Это ведет к политическим играм и всему остальному неприглядному грязному белью. Ну его нафиг.
оплата = ЗП + бонус.
система сложная, вовсе не за естимейт.
ноу-хау.
система сложная, вовсе не за естимейт.
ноу-хау.
да, continious delivery я употребил слегка в другом смысле.
и да, должен заметить, я долго думал, как сформулировать свои мысли,
но после того, как наткнулся на Вашу отличную статью, просто был в шоке, насколько точно все можно описать :)
тем не менее, решил еще раз обдумать и написать что-то свое. как там кто-то советовал, пишите и тренируйтесь :)
но после того, как наткнулся на Вашу отличную статью, просто был в шоке, насколько точно все можно описать :)
тем не менее, решил еще раз обдумать и написать что-то свое. как там кто-то советовал, пишите и тренируйтесь :)
Разрешите, немного покритиковать вашу преамбулу.
Икхак Адизес выделяет четыре основные функции менеджмента PAEI (Production, Administration, Entrepreneurship and Integration). Доведение дела до конца лежит в исполнительной области (Production). Так например, военный которому приказано копать от забора до обеда, отлично выполнит эту задачу до конца, но это не будет иметь к предпринимательству (Entrepreneurship) ни какого отношения. Предпринимателю больше свойственно постоянно генерировать новые идеи, задавать вопрос: «а что если», и сомневаться в уже принятых решениях.
Кстати, индекс предпринимательской активности зависит от культуры. Так например в США 10% людей стали или попытались стать предпринимателями. В России – 2%, в Украине – 6%, в Беларуси думаю не более 1%.
Идею довести проект до конца, считаю немного утопичной, ведь даже любой сайт можно переделывать до бесконечности стремясь к совершенству. Поэтому, основной целью того же Scrum-a, является как можно раньше получить работающий каркас на котором уже можно будет добавлять нужную функциональность.
В Agile есть интересный термин “Done Done”. Рекомендую ознакомиться с главой из книги The Art of Agile Development, она идейно очень похожа на вашу статью, только раскрыта немного шире wiki.systemsx.ch/download/attachments/42698173/done-done.pdf?version=1&modificationDate=1283333174341
Икхак Адизес выделяет четыре основные функции менеджмента PAEI (Production, Administration, Entrepreneurship and Integration). Доведение дела до конца лежит в исполнительной области (Production). Так например, военный которому приказано копать от забора до обеда, отлично выполнит эту задачу до конца, но это не будет иметь к предпринимательству (Entrepreneurship) ни какого отношения. Предпринимателю больше свойственно постоянно генерировать новые идеи, задавать вопрос: «а что если», и сомневаться в уже принятых решениях.
Кстати, индекс предпринимательской активности зависит от культуры. Так например в США 10% людей стали или попытались стать предпринимателями. В России – 2%, в Украине – 6%, в Беларуси думаю не более 1%.
Идею довести проект до конца, считаю немного утопичной, ведь даже любой сайт можно переделывать до бесконечности стремясь к совершенству. Поэтому, основной целью того же Scrum-a, является как можно раньше получить работающий каркас на котором уже можно будет добавлять нужную функциональность.
В Agile есть интересный термин “Done Done”. Рекомендую ознакомиться с главой из книги The Art of Agile Development, она идейно очень похожа на вашу статью, только раскрыта немного шире wiki.systemsx.ch/download/attachments/42698173/done-done.pdf?version=1&modificationDate=1283333174341
О доведении до конца. По-моему, не зависит это от Agile, RUP, или что-нибудь еще, или Waterfall даже.
Просто следует
* Хорошо представлять себе самому конец проекта,
* Чтобы конец проекта хорошо себе представляли Заказчик, команда, и другие «стейкхолдеры».
По-моему, это необходимо и достаточно для завершения проекта. Хорошая практика — это прямо в ТЗ, договоре, уставе у кого он есть писать, что является условием окончания — 0 критических дефектов, не более 3 некритических (как пример), всё установлено там-то и там-то, подписанный акт, оплата.
Просто следует
* Хорошо представлять себе самому конец проекта,
* Чтобы конец проекта хорошо себе представляли Заказчик, команда, и другие «стейкхолдеры».
По-моему, это необходимо и достаточно для завершения проекта. Хорошая практика — это прямо в ТЗ, договоре, уставе у кого он есть писать, что является условием окончания — 0 критических дефектов, не более 3 некритических (как пример), всё установлено там-то и там-то, подписанный акт, оплата.
Саша, привет!
А я с тобой не согласен.
Говнокодя, ради скорейшего первого прототипа ты нарушаешь Главный закон КК — повышение качества системы снижает расходы на ее разработку.
Как показыает практика, — никто потом не переписывает проект грамотно и с нуля.
А я с тобой не согласен.
Говнокодя, ради скорейшего первого прототипа ты нарушаешь Главный закон КК — повышение качества системы снижает расходы на ее разработку.
Как показыает практика, — никто потом не переписывает проект грамотно и с нуля.
Каждый хороший проект должен быть переписан с нуля хотя бы один раз.
Народная мудрость.
Народная мудрость.
Согласен.
Имею ввиду другое: переписывание готового прототипа. Обычно его и продолжают пилить далее.
Имею ввиду другое: переписывание готового прототипа. Обычно его и продолжают пилить далее.
А как насчет постоянного рефакторинга? Бывает очень соблазнительно выбросить весь код и спректировать все с нуля, но в большинстве случаев это не достижимо и никто это не позволит сделать.
Да.
Они на это отвечают, — этот код приносит нам миллионы, давайте его поддерживать дальше.
Они на это отвечают, — этот код приносит нам миллионы, давайте его поддерживать дальше.
все бывает.
просто нужно говорить с людьми на их языке.
если ты финансистам говоришь — будьте добры, давайте все перепишем, потому что не хватает IoC и без ORM проект крив архитектурно — пошлют.
а изложив что-то вроде:
— ЗП программера * 1 месяц рефакторинга * 2 программера + ЗП архитектора <<< ЗП на переписывание всего с нуля после задач N, P, Q, которые вы хотите видеть сделанными в будущем.
то есть что отрефакторив, они экономят бабло, причем убедительно и авторитетно — вполне можно договориться. ИМХО.
просто нужно говорить с людьми на их языке.
если ты финансистам говоришь — будьте добры, давайте все перепишем, потому что не хватает IoC и без ORM проект крив архитектурно — пошлют.
а изложив что-то вроде:
— ЗП программера * 1 месяц рефакторинга * 2 программера + ЗП архитектора <<< ЗП на переписывание всего с нуля после задач N, P, Q, которые вы хотите видеть сделанными в будущем.
то есть что отрефакторив, они экономят бабло, причем убедительно и авторитетно — вполне можно договориться. ИМХО.
Как я понимаю, быстрый прототип — это PoC и способ быстро собрать требования к системе.
Не факт, что прототип не будет переписан, но уж если хочется это гарантировать — можно задействовать специальные инструменты (типа Axure), которые, помимо гарантии переписывания с нуля, могут также ускорить разработку прототипа.
Не факт, что прототип не будет переписан, но уж если хочется это гарантировать — можно задействовать специальные инструменты (типа Axure), которые, помимо гарантии переписывания с нуля, могут также ускорить разработку прототипа.
переписываем, каждую пятницу рефакторинг. а после первого этапа иногда целую неделю я даю переписать. фигли, я же менеджер, вышедший из программистов, понимаю зачем это нужно.
в плане расходов — есть законы чисто программерские, а есть экономические расчеты.
например, можно сделать загрузку на месяц раньше и заработать на ней два миллиона рублей. а можно делать ее три месяца и просрать момент на рынке.
в плане расходов — есть законы чисто программерские, а есть экономические расчеты.
например, можно сделать загрузку на месяц раньше и заработать на ней два миллиона рублей. а можно делать ее три месяца и просрать момент на рынке.
Доведем каждого пациента до конца
>Когда менеджер из примера наберется опыта, он сможет укладываться в месяц, если будет говорить команде, что за две недели максимум нужно сдать проект.
То есть изначально строить отношения с коммандой на обмане и пытаться манипулировать? И какое Вы будете иметь отношение через некоторое время, когда все эти фишки выкупятся?
Заметьте, что Вы изначально походите к своей команде как к сборищу недоумков, которых надо постоянно подстегивать. Я думаю что либо Вам очень не повезло с коммандой либо…
То есть изначально строить отношения с коммандой на обмане и пытаться манипулировать? И какое Вы будете иметь отношение через некоторое время, когда все эти фишки выкупятся?
Заметьте, что Вы изначально походите к своей команде как к сборищу недоумков, которых надо постоянно подстегивать. Я думаю что либо Вам очень не повезло с коммандой либо…
В работе первые 90% проекта делаются за 10% времени, оставшиеся 10% — за 90%
Народная мудрость
Это Том Каргилл (Tom Cargill), а не народная мудрость. И в оригинале фраза звучит совсем по-другому:
«The first 90 percent of the code accounts for the first 90 percent of the development time. The remaining 10 percent of the code accounts for the other 90 percent of the development time.»
en.wikipedia.org/wiki/Ninety-ninety_rule
Статья +100, очень хорошая.
Я как, начинающий менеджер, столкнулся сейчас с ошибками, которые написаны здесь.
Теперь нужно выходить из ситуации.
Я как, начинающий менеджер, столкнулся сейчас с ошибками, которые написаны здесь.
Теперь нужно выходить из ситуации.
Зарегистрируйтесь на Хабре , чтобы оставить комментарий
Доведение проекта до конца