Comments 39
>Как же донести до «сильных мира сего», что именно для получения прибыли
а зачем бесплатно учить людей зарабывать деньги?
а зачем бесплатно учить людей зарабывать деньги?
UFO just landed and posted this here
Сами научатся со временем. Людям надо давать возможность поучиться на своем опыте. Хотя, если сами не были в позиции владельца/высокого начальника, то в большинстве случаев ничего полезного «сильным мира сего» не скажете, т.к. они мыслят в других категориях, и ваши методологические и идеологические потуги могут быть каплей в море для них.
Из статьи сложилось впечатление, что гуманными методологиями «сильные мира сего» не интересуются. Но это не совсем так. Есть много компаний, которые применяют эти методологии и у них есть свои «сильные мира сего».
На самом деле, процесс никому не интересен кроме разработчиков. Всем интересен только результат. Если гуманная методология даёт лучший результат — она будет интересна и менеджерам, и инвесторам, и техлидам. Понятия лучшего результата у всех свои. И чтобы заставить кого-то понять в чём преимущество той или иной методологии, нужно объяснять ему достоинства со стороны его понятия результата.
Причём многие понимают, что от гуманных методологий результат получается лучше. Но если быть честным, то это не всегда так. Чтобы гуманные методологии действовали в команде должны быть взрослые (с ментальной точки зрения) люди, которых не надо постоянно гнать кнутом. А набрать команду только из таких людей — это счастье и для самой команды, и для менеджера, и для инвестора.
На самом деле, процесс никому не интересен кроме разработчиков. Всем интересен только результат. Если гуманная методология даёт лучший результат — она будет интересна и менеджерам, и инвесторам, и техлидам. Понятия лучшего результата у всех свои. И чтобы заставить кого-то понять в чём преимущество той или иной методологии, нужно объяснять ему достоинства со стороны его понятия результата.
Причём многие понимают, что от гуманных методологий результат получается лучше. Но если быть честным, то это не всегда так. Чтобы гуманные методологии действовали в команде должны быть взрослые (с ментальной точки зрения) люди, которых не надо постоянно гнать кнутом. А набрать команду только из таких людей — это счастье и для самой команды, и для менеджера, и для инвестора.
>> Так кому же выгодны гуманные методологии?
Тому, кто умеет извлекать из них выгоду.
Программирование — творческий труд. Любые попытки конвейеризировать творчество обречены на провал или существенное снижение производительности труда.
Гибкие или гуманные методики — путь к сокращению затратной части. Кто это понимает — процветает.
Тому, кто умеет извлекать из них выгоду.
Программирование — творческий труд. Любые попытки конвейеризировать творчество обречены на провал или существенное снижение производительности труда.
Гибкие или гуманные методики — путь к сокращению затратной части. Кто это понимает — процветает.
>Программирование — творческий труд
ой ну я вас умоляю! вот что творческого в парсинге иксмеля от чужого апи и запихивания его в базу, движок котороый тоже чорне ящик и магия?
ой ну я вас умоляю! вот что творческого в парсинге иксмеля от чужого апи и запихивания его в базу, движок котороый тоже чорне ящик и магия?
>вот что творческого в парсинге иксмеля
ой ну не скажите…
1. Выбор нужных библиотек/средств/подхода.
2. Степень контроля валидности и как
3. При выборе способа «свой велосипед», но более понятный и достаточный — вообще на 100% (как загрузить, куда, к какой букве MVC и т.д.). Да, можно сказать, что все изучено вдоль и поперек, известно куда и зачем, всё типизировано, но разве каждый раз программист не вкладывает часть своего личного опыта и персональных представлений о том как должна работать система «в целом»?
А написание комментариев? Да ёпрст, даже выбор имён переменных — уже творчество (ну или определение стиля и правил написания данных имен для подсистемы в целом)!
Степень творчества в процессе разработки определяется кучей факторов (например документированностью и моделью, гайдлайном, если хотите), но всегда (!) присутствует «личная» составляющая.
Я думаю, на определение понятия творчества ссылка не нужна…
ой ну не скажите…
1. Выбор нужных библиотек/средств/подхода.
2. Степень контроля валидности и как
3. При выборе способа «свой велосипед», но более понятный и достаточный — вообще на 100% (как загрузить, куда, к какой букве MVC и т.д.). Да, можно сказать, что все изучено вдоль и поперек, известно куда и зачем, всё типизировано, но разве каждый раз программист не вкладывает часть своего личного опыта и персональных представлений о том как должна работать система «в целом»?
А написание комментариев? Да ёпрст, даже выбор имён переменных — уже творчество (ну или определение стиля и правил написания данных имен для подсистемы в целом)!
Степень творчества в процессе разработки определяется кучей факторов (например документированностью и моделью, гайдлайном, если хотите), но всегда (!) присутствует «личная» составляющая.
Я думаю, на определение понятия творчества ссылка не нужна…
Сколько способов распарсить XML вы знаете? А сколькими способами можно написать код? Пока вы придумывали способы, вы занимались творчеством… :)
Японский опыт показывает, что даже сборку автомобилей не надо конвейезировать и формализировать по максимуму. Люди вообще такие существа, им не нравится выполнять роль автоматов. Они работают лучше, когда есть какой-то простор.
Поделитесь материалами. Правда интересно как японцы смогли обойтись без конвейера при сборке машин
Совсем без конвейера они, конечно, не обошлись. Но они отказались от ситуации, когда каждый работник стоит строго в одном месте и строго крутит одну гайку. При японской организации работник более универсален, он по необходимости может переходить с одного участка производства на другой, а главное ему делигируется возможность принятия самостоятельных решений вплоть до полной остановки конвейера. Подробнее можно почитать, к примеру, в 22 главе книги Фрэнсиса Фукуямы «Доверие». Есть статья в википедии, но не вполне удачная: en.wikipedia.org/wiki/Kanban
ну про канбан и JIT это понятно.
Ротация между участками конвейера, насколько я знаю, не является чем-то «выдающимся» и использовалось повсеместно довольно давно.
Просто «сборку автомобилей не надо конвейезировать» я воспринял как «полный отказ от конвейера при сборке автомобилей». ну и мне стало любопытно — а как же тогда если не конвейер.
Ротация между участками конвейера, насколько я знаю, не является чем-то «выдающимся» и использовалось повсеместно довольно давно.
Просто «сборку автомобилей не надо конвейезировать» я воспринял как «полный отказ от конвейера при сборке автомобилей». ну и мне стало любопытно — а как же тогда если не конвейер.
создание автоматизированного конвейера по сборке автомобилей — куда уж более творческая работа)
Ваш итог написан с позиции специалиста (исполнителя), но не обязательно оправдан для вышеперечисленных других ролей. В жизни поступают так, как будет достигаться более эффективный результат.
Вот я про то же. Получается что «любви и не было» :-) Вы тут играйтесь в команду, а прийдет дядя и одним ударом размажет весь это коммунизм, если ему он станет невыгодным.
На самом деле есть проекты которые основаны именно на гуманности и профессионализме с большой буквы, где творчество и уважение к специалистам выше эффективности. Взять тот же линукс или FSF ;-) Но насколько они выгодны?
На самом деле есть проекты которые основаны именно на гуманности и профессионализме с большой буквы, где творчество и уважение к специалистам выше эффективности. Взять тот же линукс или FSF ;-) Но насколько они выгодны?
>относятся к ним как к скоту, они пишут кучу дерьма
Вещи, вообщем то, слабо связанные между собой.
И качество продукта, даже пожалуй в большей мере зависит от того, насколько руководитель проекта любит свой проект, как мотивирует команду не в плане «подносить кофе», премии каждую неделю, и т.д., а именно «технологически». Насколько в команде и в проекте (в стане разработчиков) царит атмосфера «инновационности», «изобретательства».
Программисту, если он твердо знает, что он хочет от того, что делает (а я считаю, что хотеть он должен собственного развития + денег, именно в таком порядке) должно быть глубоко по-барабану на эмоциональное напряжение по цепочке топ-менеджер -> руководитель проекта -> старший разработчик, если только конечно сзади него не стоят с молотком и не бьют по голове при каждом удобном случае.
Пусть менеджер пытается создать идеальный процесс, в независимости от кучи говна на своей голове, а программист пишет красивый код, используя для этого все свои и старшего более опытного коллеги знания, пусть даже и кусками, обрывками и в промежутках между «взбучками». И всё будет хорошо и у первого и у последнего. А как на долго они там задерживаются обычно им самим должно становиться ясно в первые пару декад. Их же, как пчёл не убивают. В чем проблема учиться приносить хороший мёд? С новыми ульями сейчас по-моему проблем нету.
По-моему уж где-где, а в ИТ-отрасли, такой проблемы есть менее всего. Переносимость знаний гораздо выше чем где бы то ни было.
Вещи, вообщем то, слабо связанные между собой.
И качество продукта, даже пожалуй в большей мере зависит от того, насколько руководитель проекта любит свой проект, как мотивирует команду не в плане «подносить кофе», премии каждую неделю, и т.д., а именно «технологически». Насколько в команде и в проекте (в стане разработчиков) царит атмосфера «инновационности», «изобретательства».
Программисту, если он твердо знает, что он хочет от того, что делает (а я считаю, что хотеть он должен собственного развития + денег, именно в таком порядке) должно быть глубоко по-барабану на эмоциональное напряжение по цепочке топ-менеджер -> руководитель проекта -> старший разработчик, если только конечно сзади него не стоят с молотком и не бьют по голове при каждом удобном случае.
Пусть менеджер пытается создать идеальный процесс, в независимости от кучи говна на своей голове, а программист пишет красивый код, используя для этого все свои и старшего более опытного коллеги знания, пусть даже и кусками, обрывками и в промежутках между «взбучками». И всё будет хорошо и у первого и у последнего. А как на долго они там задерживаются обычно им самим должно становиться ясно в первые пару декад. Их же, как пчёл не убивают. В чем проблема учиться приносить хороший мёд? С новыми ульями сейчас по-моему проблем нету.
По-моему уж где-где, а в ИТ-отрасли, такой проблемы есть менее всего. Переносимость знаний гораздо выше чем где бы то ни было.
Как пчеловод в третьем поколении хочу обратить внимание, что пчёлам оставляют примерно 1-5 кг мёда, тот который трудно выкатать, остальное заменяют сахаром (так называемся зимняя подкормка). Так же не могу себе представить, как в улей можно сыпать серу. Есть практика, что после того как мёд откатали, пчёл просто вытряхивают из улья. Проклятые атлантисты называют это «русский стиль пчеловодства», знаю, что такая практика широко применяется на Кавказе. Пчёл осенью выкидывают, а весной закупают пчелиные отводки (молодые пчелиные семьи).
Как человек последнее три года работающего над Agile Project Management Tool (TargetProcess, больше тысячи клиентов, в пятёрке мировых лидеров проджект менеджмент тулов с фокусировкой на Аджайл (XP, Scrum и Kanban), хочу заметить что Аджайл может быть выгоден как инвесторам так и непосредственно разработчиком. Если исходить из определения, что успешность методологии определяется успехом продуктов, то можно обратить внимание что SalesForce, Skype и Facebook работают по Scrum. Здесь типичный win-win approach. Современные инвесторы, стараются не трогать внутреннею кухню, и оставить «психбольницу в руках пациентов».
Мне кажется здесь больший конфликт между стремлением оптимизировать расходы (что более свойственно для аутсорсеров) и выпустить достойный продукт для которого нужна долгосрочная перспектива с высоким человеческим потенциалом, качеством кода и т.д. В большинстве продуктовых компаний в основании компании стоят программисты, и таких проблем попросту не возникает.
Как человек последнее три года работающего над Agile Project Management Tool (TargetProcess, больше тысячи клиентов, в пятёрке мировых лидеров проджект менеджмент тулов с фокусировкой на Аджайл (XP, Scrum и Kanban), хочу заметить что Аджайл может быть выгоден как инвесторам так и непосредственно разработчиком. Если исходить из определения, что успешность методологии определяется успехом продуктов, то можно обратить внимание что SalesForce, Skype и Facebook работают по Scrum. Здесь типичный win-win approach. Современные инвесторы, стараются не трогать внутреннею кухню, и оставить «психбольницу в руках пациентов».
Мне кажется здесь больший конфликт между стремлением оптимизировать расходы (что более свойственно для аутсорсеров) и выпустить достойный продукт для которого нужна долгосрочная перспектива с высоким человеческим потенциалом, качеством кода и т.д. В большинстве продуктовых компаний в основании компании стоят программисты, и таких проблем попросту не возникает.
«Ему нужна прибыль, как можно больше и быстрее.» Совершенно не факт. Если человек совершнает долгосрочные инвестиции, то ему не требуется получить прибыль как можно быстрее.
А в Qsoft какую методологию применяют? ;)
Ммм… как мне кажется, нет никакой «игры в гуманизм». Просто сейчас такая стратегия, похоже, приносит лучшие результаты.
В Мск толковых разработчиков нехватает, поэтому все и стремятся «сохранить и приумножить» толковых работников у себя. Еслиб работы нехватало — было бы наоборот.
В Мск толковых разработчиков нехватает, поэтому все и стремятся «сохранить и приумножить» толковых работников у себя. Еслиб работы нехватало — было бы наоборот.
Разговоры про эффективность в таком черно-белом ракурсе подошли бы для бизнеса выращивания и продажи картофеля или для завода. В разработке же очень сложно понять, что именно повлияло на тот или иной исход/результат проекта, поэтому подохды выбираются скорее по субьективным ощущениям
Ой, как вы весело переврали всё.
«Ему нужна прибыль, как можно больше и быстрее.»
Допустим, это так.
«Инвестору наплевать, какой в разработке программного обеспечения используется процесс.»
Если ему важно как можно быстрее вернуть инвестиции (см.выше), то он предпочтёт ту организацию работы, которая быстрее даёт отдачу, а именно это предлагают итерационные процессы с короткими итерациями.
«Менеджеру проекта … нужно, чтобы проект… а) Был довольно точно описан, согласован с Заказчиком и требования не менялись. Тогда его несложно оценить, распланировать этапы работ и водопадно выполнить.»
Менеджеру проекту нужно, чтобы 1) заказчик был доволен работой с ним 2) проект был управляемым, т.е. достижение целей проекта было предсказуемым в любой момент хода проекта. Если заказчик — инвестор, то как сказано выше, они заинтересован в наискорейшей отдаче, а не в водопаде, в котором он рискует ПОТОМ получить то, что было согласовано на выходе этапа анализа, но не то, что на самом деле нужно ему/рынку СЕЙЧАС.
Управляемость может обеспечиваться не столько отдельными этапами разработки требований, планирования и исполнения (что всё равно оставляет большие риски, как показывают последние десятилетий разработки софта), но и выходом команды на определённую устойчивую скорость разработки (velocity).
«Ему нужна прибыль, как можно больше и быстрее.»
Допустим, это так.
«Инвестору наплевать, какой в разработке программного обеспечения используется процесс.»
Если ему важно как можно быстрее вернуть инвестиции (см.выше), то он предпочтёт ту организацию работы, которая быстрее даёт отдачу, а именно это предлагают итерационные процессы с короткими итерациями.
«Менеджеру проекта … нужно, чтобы проект… а) Был довольно точно описан, согласован с Заказчиком и требования не менялись. Тогда его несложно оценить, распланировать этапы работ и водопадно выполнить.»
Менеджеру проекту нужно, чтобы 1) заказчик был доволен работой с ним 2) проект был управляемым, т.е. достижение целей проекта было предсказуемым в любой момент хода проекта. Если заказчик — инвестор, то как сказано выше, они заинтересован в наискорейшей отдаче, а не в водопаде, в котором он рискует ПОТОМ получить то, что было согласовано на выходе этапа анализа, но не то, что на самом деле нужно ему/рынку СЕЙЧАС.
Управляемость может обеспечиваться не столько отдельными этапами разработки требований, планирования и исполнения (что всё равно оставляет большие риски, как показывают последние десятилетий разработки софта), но и выходом команды на определённую устойчивую скорость разработки (velocity).
Верно. Забыл описать данный тип менеджера, который желает понравится и заигрывает с Заказчиком, подминая под себя программистов — скорее политик, которому здоровье продукта через пару-тройку лет особо не важно.
Простой пример. Построен дом. Ведутся кровельные работы. Руководитель проекта, желая понравится, договаривается… поменять тип и число свай. Ему это конечно политически выгодно — но с точки зрения процесса строительства он не прав :-)
Архитектурно-строительные примеры из жизни учат нас тому, что ТЗ все-таки нужно, и менять цвет окон это одно, а прибивать унитаз к потолку — совсем другое. И за такие политические заигрывания с Клиентом, который сам не знает чего хочет, менеджера могут и в цемент залить :-)
Простой пример. Построен дом. Ведутся кровельные работы. Руководитель проекта, желая понравится, договаривается… поменять тип и число свай. Ему это конечно политически выгодно — но с точки зрения процесса строительства он не прав :-)
Архитектурно-строительные примеры из жизни учат нас тому, что ТЗ все-таки нужно, и менять цвет окон это одно, а прибивать унитаз к потолку — совсем другое. И за такие политические заигрывания с Клиентом, который сам не знает чего хочет, менеджера могут и в цемент залить :-)
Я не понимаю, откуда вы берёте про «заигрывает» и «подминает». Руководитель проекта работает на удовлетворённость заказчика, это аксиома. Ему за это платят деньги — чтобы заказчик был доволен. Это не значит, что он работает ТОЛЬКО с его интересами. Это не значит, что он не учитывает долговременные соображения, это не значит, что он плюет на архитектуру.
А аналогии со строительными работами и ПО давно показали свою ограниченность, хотя бы потому, что величины рисков и длительностей фаз проектирование/сооружение просто несопоставимы.
А аналогии со строительными работами и ПО давно показали свою ограниченность, хотя бы потому, что величины рисков и длительностей фаз проектирование/сооружение просто несопоставимы.
Это зависит от компании и проекта. Я отношусь к ProjectManager буквально — люди должны а) обоснованно выбрать проектный процесс (RUP, Iconix, Agile/Scrum, вопопад), б) подготовить план управления рисками и другие планы если нужно, в) расчитать бюджет, г) сформировать команду — но главная их задача — ДОСТИЧЬ ЦЕЛИ ПРОЕКТА в рамках бюджета. Сделать проект А в этом году за Б рублей. Сделает — остается, не сделает — уходит.
Не всегда менеджеры проекта общаются напрямую с Заказчиками. Общение может идти через руководителя проектного отдела, аналитиков, account-менеджеров.
Но в чем согласен с Вами, так это в удобной концепции Agile для руководителя проекта — открытость, желание решить задачи клиента, встреча изменений с распростертыми объятьями. Но к сожалению такая «свобода» таит сколько рисков, что ТЗшный подход нередко, в моей практике, приносил лучший результат.
Не всегда менеджеры проекта общаются напрямую с Заказчиками. Общение может идти через руководителя проектного отдела, аналитиков, account-менеджеров.
Но в чем согласен с Вами, так это в удобной концепции Agile для руководителя проекта — открытость, желание решить задачи клиента, встреча изменений с распростертыми объятьями. Но к сожалению такая «свобода» таит сколько рисков, что ТЗшный подход нередко, в моей практике, приносил лучший результат.
Если специалист хочет вырасти в руководителя разработки, техдира, менеджера проектов
Желание программиста вырасти в лида или техдира понятно, но вот в менеджера проектов… это имхо наоборот регресс :)
> Как же донести до «сильных мира сего»…
Что дешевле? Новая семья или 20 кг меда? Бизнес всегда выберет оптимальный вариант с точки зрения затрат — про это еще Маркс писал. И не так уж он был неправ.
Что дешевле? Новая семья или 20 кг меда? Бизнес всегда выберет оптимальный вариант с точки зрения затрат — про это еще Маркс писал. И не так уж он был неправ.
Sign up to leave a comment.
«Серное» пчеловодство или игра в гуманизм