Comments 37
Честно говоря, напоминает гадскую рекламу новостных сайтов: на баннере написано, что «Сенсация! Запущен первый в мире телепортатор!», на сайте в заголовке статьи — что учоныи в лаборатории произвели телепортацию микрочастицы на расстояние 1 метр, а в тексте статьи выясняется, что речь идет об очередном эксперименте по квантовой сцепленности (т.е. речь идет вообще о передаче информации по классическому каналу связи).
Точно так же и здесь: «Процессы фигня! Софтверная инженерия мертва!», а в статье только предостережения от излишнего расчета на метрики в процессе разработки, и о том, что в программировании большую роль играет экспериментирование.
Короче!
Народу не нужны нездоровые сенсации! Народу нужны здоровые сенсации!!!
Точно так же и здесь: «Процессы фигня! Софтверная инженерия мертва!», а в статье только предостережения от излишнего расчета на метрики в процессе разработки, и о том, что в программировании большую роль играет экспериментирование.
Короче!
Народу не нужны нездоровые сенсации! Народу нужны здоровые сенсации!!!
Странно, может мы разные статьи читали?
Статья не просто предостерегает, а говорит прямо о невозможности контроля и о, собственно, ненужности его.
А если учесть, кто автор, то эти слова окрашиваются в особенные цвета…
Статья не просто предостерегает, а говорит прямо о невозможности контроля и о, собственно, ненужности его.
А если учесть, кто автор, то эти слова окрашиваются в особенные цвета…
> понимание математики проще измерить
колоссальное заявление!
> «чем более вы фокусируетесь на контроле, тем более вероятно, что вы работаете на проекте, который в итоге принесет очень мало прибыли»
Логика потрясает.
Не делайте дешёвых проектов, делайте проекты, которые приносят много бабла!
Вот примерно так и на качестве экономят.
Вообще в любом деле успех это всегда баланс между свободой/творчеством и стандартами/методологиями. Важно найти этот баланс.
колоссальное заявление!
> «чем более вы фокусируетесь на контроле, тем более вероятно, что вы работаете на проекте, который в итоге принесет очень мало прибыли»
Логика потрясает.
Не делайте дешёвых проектов, делайте проекты, которые приносят много бабла!
Вот примерно так и на качестве экономят.
Вообще в любом деле успех это всегда баланс между свободой/творчеством и стандартами/методологиями. Важно найти этот баланс.
Не делайте дешёвых проектов, делайте проекты, которые приносят много бабла!
Неа, скорее «не делайте дорогих проектов, которые приносят мало бабла, а делайте дешевые проекты, которые приносят много бабла, тогда контроль будет не так важен» — классическое ПОДЕПРОДО =)
Если что-то делать сложно, это не значит, что нужно от этого отказываться. Мир не бывает черным или белым. Так и здесь — автор говорит о том, что нельзя переоценивать вклад метрик в достижение успеха, только и всего.
Также он говорит, что метрики не есть обязательная часть каждого успешного проекта. Но ни слова о том, что отсутсвие метрик — залог успеха. Так что статья не только провокационная, но еще и популистическая в некотором роде.
Также он говорит, что метрики не есть обязательная часть каждого успешного проекта. Но ни слова о том, что отсутсвие метрик — залог успеха. Так что статья не только провокационная, но еще и популистическая в некотором роде.
Шаблон затрещал и не выдержал. То ли перевод подкачал, то ли в оригинале слишком много несвязных высказываний.
Интересная заметка. Узнаю Демарко :)
Peopleware (Человеческий фактор: успешные проекты и команды) написан несколько в другом ключе. Но по сути про то же — книга ставит акцент на организации условий работы команды, а не на инжиниринг.
Кстати, считаю что это одна из лучших книг про организацию работы компании. Позитивно написана, и читается легко. Кто не читал и интересуеться темой — рекомендую.
Peopleware (Человеческий фактор: успешные проекты и команды) написан несколько в другом ключе. Но по сути про то же — книга ставит акцент на организации условий работы команды, а не на инжиниринг.
Кстати, считаю что это одна из лучших книг про организацию работы компании. Позитивно написана, и читается легко. Кто не читал и интересуеться темой — рекомендую.
Интересная информация к размышлению. Спасибо
Возмущенным: «Не надо воспринимать всё так критично. Надо, как мне кажется, просто подумать над этим.
Мысль очень интересная
Возмущенным: «Не надо воспринимать всё так критично. Надо, как мне кажется, просто подумать над этим.
Мысль очень интересная
Спасибо за перевод, сам бы вряд ли наткнулся на оригинал. Мысли и правда очень интересные. Погоня за всеобъемлющим контролем малоэффективна, то факт, надо уметь балансировать на грани контроля и бесконтрольности.
Воспринимать статью критично тоже не стоит, все останутся при своем мнении, если вы нашли для себя оптимальную методику разработки, то незачем тут пинать кого-то за полезные размышления и переосмысления спустя годы.
Воспринимать статью критично тоже не стоит, все останутся при своем мнении, если вы нашли для себя оптимальную методику разработки, то незачем тут пинать кого-то за полезные размышления и переосмысления спустя годы.
Замечательная аналогия по-моему, правда оффтопик. New Scientist: How chaos drives the brain
В избранное.
P.S.
Офтоп: а что с википедией, лежит она что-то, м?
P.S.
Офтоп: а что с википедией, лежит она что-то, м?
Менеджеры! Смиритесь с технократией!
Мотивируйте, мотивируйте, мотивируйте! :)
Всё что требуется от Вас, это чёткого понимания
СВОИХ целей и задач. А в остальном придется положиться
на технарей.
Мотивируйте, мотивируйте, мотивируйте! :)
Всё что требуется от Вас, это чёткого понимания
СВОИХ целей и задач. А в остальном придется положиться
на технарей.
ИМХО если без особого контроля раздолбаю дать писать проект, сдача которого принесет зарплату не одному ему, то плакали их денюшки.
инжиниринг? теперь по диплому я инжинир?
Статья ни о чём. Я думаю это уже старческий маразм. Он как и любой другой старик, живёт воспоминаниями про огромные мейнфреймы и разработкой системы управления багажом для даллаского аэропорта.
«Множество проектов развивались без всякого контроля, но все-таки в результате получились превосходные продукты — такие, как GoogleEarth или Wikipedia.» Это он о чём? С каких это пор наполнение контента — это и есть программный продукт?
«Но это не совсем то, что инжиниринг ПО стал значить.» Надо сказать иначе «Инжиниринг ПО — это не то, что ты думаешь, ДеМарко.»
«Множество проектов развивались без всякого контроля, но все-таки в результате получились превосходные продукты — такие, как GoogleEarth или Wikipedia.» Это он о чём? С каких это пор наполнение контента — это и есть программный продукт?
«Но это не совсем то, что инжиниринг ПО стал значить.» Надо сказать иначе «Инжиниринг ПО — это не то, что ты думаешь, ДеМарко.»
Читал оригинал, рад, что сделали перевод.
Статья ценна не свежестью мыслей, а именно тем, что выбивает табуретку из под фанатов метрик. Часто в дискуссии с таким любителем экселевских таблиц, набитых ROI/KPI/SLOC… всплывает заезженное (и перевранное по эффекту телефона) «нельзя управлять неизмеряемым». Теперь их ткнуть носом в автора и его раскаяние.
BTW, вижу некоторую агрессивность комментариев — может это надо было в «Управлении проектами» постить?
Статья ценна не свежестью мыслей, а именно тем, что выбивает табуретку из под фанатов метрик. Часто в дискуссии с таким любителем экселевских таблиц, набитых ROI/KPI/SLOC… всплывает заезженное (и перевранное по эффекту телефона) «нельзя управлять неизмеряемым». Теперь их ткнуть носом в автора и его раскаяние.
BTW, вижу некоторую агрессивность комментариев — может это надо было в «Управлении проектами» постить?
Я думаю, что ДеМарко в чем-то прав. Понравилась мысль, что тотальный контроль нужен только в никудышных проектах — очень верно подмечено, но таких проектов большинство. Имхо, тут надо все-таки глубже смотреть на вопрос.
Откуда возникла потребность в создании методов оценки и контроля хода выполнения проектов, а также PMI и прочих методологий? Просто хотелось сделать разработку ПО сделать контролируемым производственным процессом, т.е. превратить ее в конвейер с понятными для инвесторов параметрами (столько-то вложили — столько-то получили через такой-то срок). Фигня только в том, что писать софт — это не гайки крутить, т.е. данная работа требует творчества (правда, можно и галеру быдлокодеров посадить, если вас не смущает что главным преимуществом продукта будет красивая коробочка и дорогая реклама). Получается, что, работая на проектной основе с фиксированными сроками, требованиями к качеству, бюджетом и ресурсами, менеджеру постоянно приходится бороться с энтропией в проекте: то у клиента «полет мысли» включился, то программисты что-то накосячили и теперь из-за переделок нужно думать, как бы не выйти за ограничения по времени и срокам, и как багу выдать за фичу. Другой вариант — превратить разработку в постоянный и непрерывный процесс с короткими циклами, и в конце каждого цикла иметь работающий продукт, но с неполным функционалом (собственно, это и есть подход гибких методологий). Венчурные проекты — это вообще отдельная история, потому что они действительно управляются по-другому, так что не стоит смешивать их с довольно нудным бизнесом заказной разработки ПО.
Есть хорошая статья Алистера Коуберна «Каждому проекту своя методология». На мой взгляд, правильный подход: каждый метод управления — это способ «подстелить себе соломку» в определенном месте, поэтому если чувствуешь, что где-то будет прокол — используй соответствующий метод, чтобы снизить риски, если нет, то не трать время и ресурсы. А если всего боишься, то PM'ом тебе не быть.
Откуда возникла потребность в создании методов оценки и контроля хода выполнения проектов, а также PMI и прочих методологий? Просто хотелось сделать разработку ПО сделать контролируемым производственным процессом, т.е. превратить ее в конвейер с понятными для инвесторов параметрами (столько-то вложили — столько-то получили через такой-то срок). Фигня только в том, что писать софт — это не гайки крутить, т.е. данная работа требует творчества (правда, можно и галеру быдлокодеров посадить, если вас не смущает что главным преимуществом продукта будет красивая коробочка и дорогая реклама). Получается, что, работая на проектной основе с фиксированными сроками, требованиями к качеству, бюджетом и ресурсами, менеджеру постоянно приходится бороться с энтропией в проекте: то у клиента «полет мысли» включился, то программисты что-то накосячили и теперь из-за переделок нужно думать, как бы не выйти за ограничения по времени и срокам, и как багу выдать за фичу. Другой вариант — превратить разработку в постоянный и непрерывный процесс с короткими циклами, и в конце каждого цикла иметь работающий продукт, но с неполным функционалом (собственно, это и есть подход гибких методологий). Венчурные проекты — это вообще отдельная история, потому что они действительно управляются по-другому, так что не стоит смешивать их с довольно нудным бизнесом заказной разработки ПО.
Есть хорошая статья Алистера Коуберна «Каждому проекту своя методология». На мой взгляд, правильный подход: каждый метод управления — это способ «подстелить себе соломку» в определенном месте, поэтому если чувствуешь, что где-то будет прокол — используй соответствующий метод, чтобы снизить риски, если нет, то не трать время и ресурсы. А если всего боишься, то PM'ом тебе не быть.
Вообще-то экстремизм — зло.
Всё просчитать нельзя и вообще без расчетов тоже нельзя.
Надо найти грамотный баланс.
А то, что автор не знает, как измерить этику — его проблема. Кто-то это знает. Даже один ученый психологии изобрел модель, по которой все разнообразные и разномастные методики и классификации можно свести в примерно одну систему координат. См. понятие «Пентабазис». medbookaide.ru/books/fold1002/book1226/content.php
В-общем и целом это раскидка объекта по осям:
— пространство
— время
— энергия
— информация
И сбор всего в пятой точке — субстрате, который интегрирует все четыре и является пятым элементом.
Кароче «5 элемент» не на пустом месте сняли :)
До Менделеева тоже думали, что химия — это что-то такое!
Кароче гуру метнулся из крайне-левого положения в крайне-правое, что тоже не есть гут.
Всё просчитать нельзя и вообще без расчетов тоже нельзя.
Надо найти грамотный баланс.
А то, что автор не знает, как измерить этику — его проблема. Кто-то это знает. Даже один ученый психологии изобрел модель, по которой все разнообразные и разномастные методики и классификации можно свести в примерно одну систему координат. См. понятие «Пентабазис». medbookaide.ru/books/fold1002/book1226/content.php
В-общем и целом это раскидка объекта по осям:
— пространство
— время
— энергия
— информация
И сбор всего в пятой точке — субстрате, который интегрирует все четыре и является пятым элементом.
Кароче «5 элемент» не на пустом месте сняли :)
До Менделеева тоже думали, что химия — это что-то такое!
Кароче гуру метнулся из крайне-левого положения в крайне-правое, что тоже не есть гут.
все правильно: для проектов типовых, посчитанных нужны метрики и контроль. Го заниматься ими неинтересно ни с профессиональной ни с финансовой точки зрения. А для инновационных вещей, обещающих сверхприбыль контроль скорее губителен.
Ну и все собственно.
Ну и все собственно.
Ну очень режет глаз:
" натуральной науки " — natural science, что переводится как «естественнонаучные дисциплины».
" натуральной науки " — natural science, что переводится как «естественнонаучные дисциплины».
а мне кажется что у демарко последнее время не клеются проекты… из-за жосткого контроля… вот он и пришёл к такому выводу…
я его мнение на носу себе никогда не зарублю… тока приму к сведению… не более…
я его мнение на носу себе никогда не зарублю… тока приму к сведению… не более…
кстати книги Тома очень неплохие. следовать им как заветам ильича кончено не стоит, но структурируют мысли они хорошо.
Sign up to leave a comment.
Том ДеМарко: инжиниринг ПО — идея, время которой прошло?