mmoustaf 101 Жалоба Опубликовано: 11 л Что за словоблудие? Ради искусства икебаны, что ли? Я ничего не перепутал? Да, ради икебаны. Задачи на олимпиадах - это типичная икебана. А в жизни, когда тебе приходит бизнес-реквест, часто получается, что пользователь хотел не только этого, или не этого вообще. Быдлокодер - он реквест исполнит, пусть даже олимпийским кодом, а потом начнет: этого не было в спеке, этого тоже. Сами виноваты, что не так работает. А программист - для которого важен не код сам по себе, а результат - он в силу своих знаний он пользователю на темные места сам укажет. Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах
333 546 Жалоба Опубликовано: 11 л Да, ради икебаны. Задачи на олимпиадах - это типичная икебана.Нет, не икебана. Спорт (мотивация) и искусство (ценность результата) — да. Вид — нет. Это, как ни крути, программирование, а не мелкая моторика и чувство формы и цвета.Программист уже давно не просто кодит. Поэтому, тот кто только программирует - быдлопрограммер.Какой перекос в терминологии! Да уж, отстал я от жизни. „Обычной“. Тот, кто только кодит, то не программер, а кодер. Возможно, „быдло“ — зависит от качества результатов его деятельности. Программист, помимо кодерства (которое он должен уметь) обязан думать о решении конечной задачи. Иначе он просто кодер. Причём, программист тоже может быть „быдло“ — зависит от его способности анализировать и выбирать наибоее подходящие для задачи архитектуру, инструменты… И быдлопрограммер ≠ кодер, ибо его функции (изначально, по идее) иные, просто он такой хреновый программист.А нормальный программер он умеет немного больше, для него процесс кодирования не основной.Кто ж спорит.…а вот бузи нес и потоки…По-моему, тут больше речь уже не о программировании, а о системном анализе. Или уже забыли такое понятие? Несомненно, программист должен обладать способностями к системному анализу, иначе быть ему просто кодером, но это не его основная деятельность, поскольку постигнуть конкретную предметную область (экономику, суровую математику, экспериментальную или теоретическую физику, социологию и т.п.) на уровне соответствующего специалиста нереально (за редким исключением). Я пока только ещё более утвердился во мнении, что „всё смешалось в доме…“. PS. Как может так „съезжать“ терминология в, казалось бы, далеко не гуманитарной области? Это, что, эффекты замкнутых сообществ? Локальная профессиональная деформация в отдельно взятом месте/коллективе? Поразительно. Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах
mmoustaf 101 Жалоба Опубликовано: 11 л Несомненно, программист должен обладать способностями к системному анализу, иначе быть ему просто кодером, но это не его основная деятельность, поскольку постигнуть конкретную предметную область (экономику, суровую математику, экспериментальную или теоретическую физику, социологию и т.п.) на уровне соответствующего специалиста нереально (за редким исключением). Это как раз его основная деятельность. Точнее потихоньку плавно перетекает туда. Ему конечно не обязательно скажем быть Герчиком, но понимать как и что работает на уровне средней руки специалиста соответствующей области он обязан. Точнее с моей точки зрения это желательно. PS. Как может так „съезжать“ терминология в, казалось бы, далеко не гуманитарной области? Это, что, эффекты замкнутых сообществ? Локальная профессиональная деформация в отдельно взятом месте/коллективе? Поразительно. Здравствуйте, доктор. Нет, не икебана. Спорт (мотивация) и искусство (ценность результата) — да. Вид — нет. Это, как ни крути, программирование, а не мелкая моторика и чувство формы и цвета. Это именно "моторика" и "чувство формы", только для мозга. Тебе дают отвлеченную от жизни неизменяемую задачу с определенными фиксированными ограничениями и ты выращиваешь программную икебану. Никто ж не говорит, что это плохо. Это очень клево. К сожалению в реальных проектах это не всегда применимо. Точнее применимо в компиляторах, осах и прочих гуглосерчах. Ну так это как и любой спорт, с жизнью очень слабо сочетается. Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах
mmoustaf 101 Жалоба Опубликовано: 11 л А по поводу все смешалось. Я давно считаю, что программер - это такой универсальный дядька. который умеет все Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах
Alkinoy 56 Жалоба Опубликовано: 11 л От обычной.Программист уже давно не просто кодитПоэтому, тот кто только программирует - быдлопрограммер. Это к качеству кода не относится.Это относится к уровню в иерархии. А нормальный программер он умеет немного больше, для него процесс кодирования не основной.И в обычной жизни быдлопрограммер начинает фигачит ради программирования, без удержи переделывая код на супер-пупер эффективный, или просто делая то, что спустят сверху. Код он может понимает и лучше всех, а вот бузи нес и потоки - не очень.А так, Если рассматривать понятие быдлопрограммера с точки зрения качества кода, безусловно прав ты.странно, с каких пор эффективный исполнитель стал быдлокодером? в каждой компании обязательно должен быть ас именно программирования. Который знает, как правильно обратиться к ресурсам системы. как сделать это эффективно. подводные камни используемых библиотек и прочего. то, что менеджер проекта не умеет его применить правилно не делает программиста быдлокодером. везде должен быть баланс, потому что без кодеров - начинают писать в стиле "маляра Шлемиэля..."Маляр Шлемиэль подрядился красить пунктирные осевые линии на дорогах. В первый деньон получил банку краски, поставил ее на дорогу, и к концу дня покрасил 300 метров осевойлинии. "Отлично!" сказал прораб, "быстро работаешь!" - и заплатил ему копейку.На следующий день Шлемиэль покрасил 150 метров. "Мда, это, конечно, не так здорово, каквчера, но приемлемо", - сказал прораб и заплатил ему копейку.На следующий день Шлемиэль покрасил 30 метров. "Всего лишь 30!" заорал прораб. "Этоникуда не годится! В первый день было в десять раз больше! В чем дело?""Ничего не могу поделать," - говорит Шлемиэль. "Каждый день я ухожу все дальше идальше от банки!" Так что часто рассказы о том, что программисты должны быть не только программистами идет от неспособности правильно организовать работу. Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах
mmoustaf 101 Жалоба Опубликовано: 11 л странно, с каких пор эффективный исполнитель стал быдлокодером? С тех пор как мало быть только эффективным исполнителем. Так что часто рассказы о том, что программисты должны быть не только программистами идет от неспособности правильно организовать работу. Это как раз правильная организация работы. Каждый член команды должен быть не только программистом. И очень желательно чтобы так было. в каждой компании обязательно должен быть ас именно программирования. Который знает, как правильно обратиться к ресурсам системы. как сделать это эффективно. подводные камни используемых библиотек и прочего. то, что менеджер проекта не умеет его применить правилно не делает программиста быдлокодером. везде должен быть баланс, потому что без кодеров - начинают писать в стиле И если этот ас уберется на низком развороте, то всему проекту придет полный и неотвратимый пиндец. Это во-первых. А во-вторых, не обязательно быть супер-пупер асом в программировании. Победит та команда, в которой эффективного аса может быть и нет, но все вместе взаимозаменяемы и кросс-функциональны. Эффективного аса можно позвать на тренинг по передаче знаний. Больше в общем-то он и не нужен. Так что часто рассказы о том, что программисты должны быть не только программистами идет от неспособности правильно организовать работу. Это такой же миф как и то, что аджайл - это "по русски тяп-ляп". Другое дело, что аджайл не везде применим. И ваще вы все так возбухаете. как будто быдлокодер в вашем понимании - это что-то плохое. Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах
Alkinoy 56 Жалоба Опубликовано: 11 л С тех пор как мало быть только эффективным исполнителем. да, конечно. хорошо, когда программист не только программит, но еще и ведет план работ, генерит отчетность, продвигает товар на рынке, дизигнерит и отвечает на вопросы пользователей. Как найдешь команду таких людей - расскажи, интересно, правда. Но моя практика показывает, что достаточно взять специалистов в своем вопросе и наладить просто нормальное управление. И если этот ас уберется на низком развороте, то всему проекту придет полный и неотвратимый пиндец. наличие аса в программирование != наличию единственного и неповторимого исполнителя. Наличие аса программирования == эффективные решения задач, отсутствие аса == не самые эффективные решения задач. Победит та команда, в которой эффективного аса может быть и нет, но все вместе взаимозаменяемы и кросс-функциональны. правильно, но с оговорками. Ты часто видел программистов, которые могут реально заменить дизайнера? именно заменить, а не так, пару каких то финтифлющек прикрутить. Или программиста, который может заменить технолога по расчету себестоимсоти производственного процесса? или программиста, способного заменить технолога на линии в цеху? или заменить схемотехника оп разводке печатных плат? все вопросы - из живых примеров проектов моих. В большинстве твоих примеров, предполагаю, будет замена одного программиста другим. то есть просто подхват какой то другой технологии/языка программирования. Поверь, асы чаще всего могут такое делать. если ас все таки есть - то это лучше, чем то же самое, но без него. Эффективного аса можно позвать на тренинг по передаче знаний. Больше в общем-то он и не нужен. все зависит от сложности проекта. на мелких проектах обычно ас нерентабелен. И ваще вы все так возбухаете. как будто быдлокодер в вашем понимании - это что-то плохое. потому что каждый о своем определении говорит. Дай определение быдлокодера. Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах
mmoustaf 101 Жалоба Опубликовано: 11 л да, конечно. хорошо, когда программист не только программит, но еще и ведет план работ, генерит отчетность, продвигает товар на рынке, дизигнерит и отвечает на вопросы пользователей. Как найдешь команду таких людей - расскажи, интересно, правда. Но моя практика показывает, что достаточно взять специалистов в своем вопросе и наладить просто нормальное управление. Не так. Не только программит но и активно участвует с пользователем в обсуждении задачи. У него достаточно бызнес знаний чтобы понять пользователя, определить белые пятна или странные места в требованиях. Он не ждет оформленного бизнес реквеста, или функциональной спецификации, а активно участвует в его появлении. наличие аса в программирование != наличию единственного и неповторимого исполнителя. Наличие аса программирования == эффективные решения задач, отсутствие аса == не самые эффективные решения задач. Не самые эффективные лучше чем неэффективные вообще. Наша задача выдать продукт. По возможности максимально эффективный. Но если он будет не самый эффективный - это не страшно. Поэтому в команде не нужны асы. Асов можно сделать самим. правильно, но с оговорками. Ты часто видел программистов, которые могут реально заменить дизайнера? именно заменить, а не так, пару каких то финтифлющек прикрутить. Или программиста, который может заменить технолога по расчету себестоимсоти производственного процесса? или программиста, способного заменить технолога на линии в цеху? или заменить схемотехника оп разводке печатных плат? все вопросы - из живых примеров проектов моих. В большинстве твоих примеров, предполагаю, будет замена одного программиста другим. то есть просто подхват какой то другой технологии/языка программирования. Поверь, асы чаще всего могут такое делать. если ас все таки есть - то это лучше, чем то же самое, но без него. Я говорю о программерах, которые могут заменить бизнес аналитика, тестера или саппортера, конечного пользователя в конце-концов. У нас таких достаточно. Есть и простые "эффективные исполнители" все зависит от сложности проекта. на мелких проектах обычно ас нерентабелен. Да и на больших тоже. Если его именно как кодера использовать. потому что каждый о своем определении говорит. Дай определение быдлокодера. так я его и дал уже выше. Это такая роль. Каждый программист он периодически быдлокодер. Но только частично. К качеству кода это не имеет никакого отношения. Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах
SlavikMIPT 73 Жалоба Опубликовано: 11 л или заменить схемотехника оп разводке печатных плат? я вижу иногда такого) все что вкладывается в понятие аса универсального - это обычно ведущий разработчик, он имеет достаточно широкий кругозор и в хорошей степени разбирается во всех областях проекта - если он захочет что то в каждой области сделать - он в итоге конечно разберется, но потратит на это больше времени, чем узкий специалист, поэтому такие люди обычно разрабатывают архитектуру проекта - определяют - как все эти узкие специалисты будут друг с другом работать Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах
Alkinoy 56 Жалоба Опубликовано: 11 л Не так. Не только программит но и активно участвует с пользователем в обсуждении задачи. У него достаточно бызнес знаний чтобы понять пользователя, определить белые пятна или странные места в требованиях. Он не ждет оформленного бизнес реквеста, или функциональной спецификации, а активно участвует в его появлении. давай на примерах? дано: проект, в котором есть фронт (веб приложение, программист и дизайнер+верстальщик), бэк (десктоп, три программера) и сервис, который обслуживает данные с фронта, бэка и еще пары автоматизированных связанных сервисов (три программера). Есть ПМ, который "активно участвует с пользователем в обсуждении задачи. У него достаточно бызнес знаний чтобы понять пользователя, определить белые пятна или странные места в требованиях". Еще есть 4 человека тестеров. Есть еще системный архитектор, но он на данном этапе работы привлекается эпизодически, поскольку архитектура им уже была создана и идет наполнение ее мясом. Случилось счастье и ПМ иммигрировал в Японию. Кого из программеров ты поставишь на его место? Я бы поставил тестера, потому что он больше других "участвует с пользователем в обсуждении задачи", ибо ему надо понимать весь процесс работы. На как долго бы я его поставил? на неделю-две, пока в проект не пришел бы новый ПМ и не вник бы в текущее положение дел. Я бы не поставил ни одного из программистов, поскольку ни один из них не участвует активно с пользователем. Только по своей части и то, только по тем вопросам, которые ему не смог объяснить ПМ. "активно участвует с пользователем в обсуждении задачи" - обычно клиент не может внятно объяснить программисту или понять объяснения программистов. На то и существует человек, с одной стороны обладающий знаниями в предметной области, с другой - в технической. Задача которого и есть - понять заказчика (со всей туевой хучей нюансов в предметной области заказчика) и объяснить на понятном программисту языке задачу (со всей туевой хучей нюансов технической реализации). Иметь программистов в предметной области - это либо очень длинный проект (скажем, собственный отдел разработки на предприятии), либо иметь много разных программистов, потому как предметные области постоянно меняются. Описанное тобой - да, имеет смысл на небольших проектах. где держать выделенных людей нецелесообразно. там да - вся группа пара-тройка человек и им приходится играть несколько ролей. Не самые эффективные лучше чем неэффективные вообще. Наша задача выдать продукт. По возможности максимально эффективный. Но если он будет не самый эффективный - это не страшно. не совсем правильно. наша задача выдать продукт в срок и с необходимой производительностью. есть проекты (или задачи в проекте), которым пофиг как она решена программно. Есть задачи, которые крайне критичны к реализации - большие данные, малые длительности процессов, большая ответственность (типа аэро-милитари-мэдикал приложений). Если это печать 3-х накладных на предприятии в день - какая разница, будет ли печать идти на две минуты дольше или иногда зависать. Если это учетка холдинга с 5-ю заводами - то глюк конвертируется в пятизначную сумму. Не смогли овормить 20-и тонный молоковоз, молоко прокисло. Повторюсь - есть проекты, критичные к реализации. Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах
SlavikMIPT 73 Жалоба Опубликовано: 11 л Alkinoy, вы на все смотрите через призму веб программирования - не везде процесс разработки поставлен так - приходит заказчик - говорит - "хочу сайт и чтобы круто было и завтра и забесплатно" и орава быдлокодеров начинает его ублажать. Многие конторы создают продукт сначала, а потом его продают и каким этот продукт будет - зависит не от пожелания заказчика, а от того - каким его видит лидер команды. За примерами далеко ходить не надо - та же Apple - две большие разницы - присасываться к существующей нише и открывать конвейер по производству одноразовых продуктов по требованиям заказчика или создавать свою нишу. Когда то люди не знали что такое ПК - если бы все разработчики сидели и ждали когда к ним придет заказчик и подробно опишет им каким должен быть компьютер - вряд ли мы бы сейчас писали в интернетах Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах
Alkinoy 56 Жалоба Опубликовано: 11 л SlavikMIPT, нет, не через веб. просто в веб это более ярко видно (кстати, в вебе много компаний со своими продуктами тоже есть). Это из опыта в проектах под веб, 1С и железячек (контроллеры, ПЛИС). Есть особенности в каждой отрасли, но принципы построения работы одинаковы. Даже если вы разрабатываете свой продукт на последующую продажу - все равно, все перечисленные мною вопросы остаются актуальны. Баланс между ценой разработки и результатом должен быть всегда. Спор с Мансуром у нас по поводу исполнителей - для серьезного проекта я предпочту команду грамотных однопрофильных специалистов команде разностаночиков. Когда то люди не знали что такое ПК - если бы все разработчики сидели и ждали когда к ним придет заказчик и подробно опишет им каким должен быть компьютер - вряд ли мы бы сейчас писали в интернетах это больше вопрос маркетнига, чем программирования (то есть производства). Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах
SlavikMIPT 73 Жалоба Опубликовано: 11 л для серьезного проекта я предпочту команду грамотных однопрофильных специалистов команде разностаночиков. это да, но должен быть человек который их объединяет - который на еженедельных собраниях поднимает различные вопросы, выслушивает мнение спецов и принимает те или иные решения - для этого он должен в каждой области разбираться хоть немного Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах
erling9 148 Жалоба Опубликовано: 11 л это да, но должен быть человек который их объединяет - который на еженедельных собраниях поднимает различные вопросы, выслушивает мнение спецов и принимает те или иные решения - для этого он должен в каждой области разбираться хоть немного угу и в идеале это трёхголовый змий из проджект менеджера, продакт менеджера и маркетолога, плотно работающий с командой с одной стороны и заказчиком\потенциальной аудиторией\аналитикой с другой) Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах
SlavikMIPT 73 Жалоба Опубликовано: 11 л erling9, нет - просто спец, который мог бы сделать работу каждого из команды, но у него на это нет времени - поэтому он руководит Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах
mmoustaf 101 Жалоба Опубликовано: 11 л давай на примерах? дано: проект, в котором есть фронт (веб приложение, программист и дизайнер+верстальщик), бэк (десктоп, три программера) и сервис, который обслуживает данные с фронта, бэка и еще пары автоматизированных связанных сервисов (три программера). Есть ПМ, который "активно участвует с пользователем в обсуждении задачи. У него достаточно бызнес знаний чтобы понять пользователя, определить белые пятна или странные места в требованиях". Еще есть 4 человека тестеров. Есть еще системный архитектор, но он на данном этапе работы привлекается эпизодически, поскольку архитектура им уже была создана и идет наполнение ее мясом. Я работаю в большом проекте критичном к реализации в большой психбольнгице. У нас есть фронт - трейдеры, мидл - TMG, и бэкофис Это трейдинговые системы. Там ответственность и быстродейтвие такие, какие не снились никому. Поскольку один маленький факап накернивает от нескольких десятков тысяч клиентов, до экономики стран целиком. Легко и просто. Толку с того, что у ПМ есть бизнес знания. Делает-же не ПМ, а программист. А если у программера вопросы к пользователю, он к ПМу идет? А если решение требует пересмотра архитектуры - к архитектору? Концепция ПМа в таких проектах зачастую абсурдна. У пользователя есть свой реквест. То как он его описал и результирующее видение ПМа по любому отличается от того, что он хочет. То как систему запроектировал архитектор еще больше уводит все от того, что хочет пользователь. И наконец выходят асы программирования, которые реализуют систему так как увидели они. А если в результате вышло эффективное "не то", то виноват тестер. или архитектор или ПМ или даже юзер который не все сказал. Правда? В результате получаем тупик и переделки эффективного кода.. У нас нет ПМа у нас есть продакт-овнер. Роль ПМ играет вся команда целиком. А продакт овнер выбивает нам необходимые вещи (ресурсы, прочее и прочее), продавливает наши требования запросы и решения.. А с пользователем мы общаемся сами. Продакт овнер нам помогает донести, что мы не можем или можем сделть, что-то лишнее и т.д. То есть он нас оберегает. И код у нас может не супер эффективный. но система в целом - удовлетворяет наиважнейшим требованиям пользователя - быстро реагирует на изменения - непрерывно развивается - эффективна в смысле запасов прочности. erling9, нет - просто спец, который мог бы сделать работу каждого из команды, но у него на это нет времени - поэтому он руководит даже больше. У него нет таких умений, но он строит эффективную работу. Ты описал скраммастера Спор с Мансуром у нас по поводу исполнителей - для серьезного проекта я предпочту команду грамотных однопрофильных специалистов команде разностаночиков Не разностаночников, а многофункциональных товарищей. Несомненно у каждого есть сильные области действия. Но команда в целом более самоорганизуема и независима. А если один однопрофильник задерживает всех, то что? Или в отпуск ушел а тут. И вообще алго-трейдинг, или позишн-кипинг для трейдинга на весь банк - это серъезно или нет? угу и в идеале это трёхголовый змий из проджект менеджера, продакт менеджера и маркетолога, плотно работающий с командой с одной стороны и заказчиком\потенциальной аудиторией\аналитикой с другой) Нет Проджект менеджер - лишнее звено С заказчиком работает вся команда целиком. И в аналитике участвует она же. Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах
erling9 148 Жалоба Опубликовано: 11 л С заказчиком работает вся команда целиком. И в аналитике участвует она же. Это не всегда работает. Особенно не работает, когда заказчик отсутствует, а аналитика сложная, объёмная и не очень однозначная. Я просто в геймдеве работаю, своя специфика есть. Для нас подход, который я описал выше, здесь работает достаточно хорошо за ооочень редкими исключениями. Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах
Alkinoy 56 Жалоба Опубликовано: 11 л Толку с того, что у ПМ есть бизнес знания. Делает-же не ПМ, а программист. А если у программера вопросы к пользователю, он к ПМу идет? А если решение требует пересмотра архитектуры - к архитектору? У нас нет ПМа у нас есть продакт-овнер. Роль ПМ играет вся команда целиком. С заказчиком работает вся команда целиком. И в аналитике участвует она же. то, что твой подход работает - доказывает наличие твоей команды. Но я считаю этот подход крайне неэффективным. не бывает нескольких ответственных. бывает только несколько безответственных. Расскажи, как в твоих случаях тогда решаются конфликты? Я правильно понимаю, что каждый программер с вопросами сам идет к заказчику и что то обсуждает и принимает какие то решения? то есть исходный продукт - некая мозаика, в которой каждая часть реализована так, как увидел конкретный исполнитель? А как руководство компании получает понятия о текущем состоянии дел? Каждый программист сам отчитывается? Это или ад, или у вас маленькая компания. сколько человек, если не секрет? А если один однопрофильник задерживает всех, то что? Или в отпуск ушел а тут. У тебя как то все факапы случаются внезапно. Вот как раз для случаев задержек, недоработок, неправильной изначальной оценки и существует ПМ. Который все эти вопросы и видит. В том числе вопросы типа "а что, если???" Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах
mmoustaf 101 Жалоба Опубликовано: 11 л Начитался слов: аджайл, скрам, кризисное программирование, мифический человеко-месяц и думаешь, что мы поверим, что ты такой умный Не, у нас такое реально работает. В конкретно моей команде скрам не очень применим, поскольку она распределенная. Но отдельные вещи именно в моей команде очень работают. А скрам и аджайл работает в соседней команде и не в одной на ура. Для этого есть специально обученные люди, вооруженными самыми современными приспособлениями в виде утюгов, пассатижей, пыточных камер и т.п. вещей, которые устраивают заказчику допрос 5-й степени в пристрастием, попутно демонстрируя ему промежуточные версии программы, чтобы вовремя скорректировать направление разработки. Очень часто задания вполне укладываются в известную информацию о рабочих процессах заказчика, а потом начинается, что хотели конечно именно этого, но другим способом. Проблема в том, что в таком случае получается испорченный телефон. И еще, когда выясняется. что "хотели конечно именно этого, но другим способом" - проходит много времени, а сроки не резиновые. Во-первых - это очень полезная вещь. У нас, например, каждый имеет свою сильную сторону и периодически устраиваются семинары, где он рассказывает остальным какие-то интересные моменты из своей области. Во-вторых, если ты попадаешь к настоящему асу, то, как написал однажды мой знакомый: "Идет 2-й день семинара, ощущаю себя полным идиотом", или как было в видео, на которое я давал линк "Я бы тоже хотел думать головой". Узнаешь совершенно неочевидные вещи. В третьих ас гораздо быстрее может разобраться с проблемой, что крайне важно в случаях ситуаций приоритетом в 1. Ну так я этого и не отрицаю. Но команда асов, она по определению слабее команды середняков "многофункционалов". Великая отечественная война в воздухе - показала. Кучу фрагов насшибали немцы, а победили - мы. Вообще-то да. Я сейчас разгребаю то, что один такой накодил. По сравнению с ним индийские программисты выглядят как неплохо подготовленные люди. В моем понимании плохое - это говнокодер. И тебе видимо тоже попался говнокодер. А быдлокодер это нормально. Ну давай я назову более длинно - массовый типа программиста или 95% программистов. Быдлокодер в индустри, это то же самое, что парашютист выходного дня в парашютизме, быдлопарашютист. Массовый то бишь. И ничего плохого в этом нет. Не, если не нравится слово быдло. ну давай заменим на политкорректный термин. будет массовый тип програмиста. а говнокодер - альтернативно одаренный программист. Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах
Alkinoy 56 Жалоба Опубликовано: 11 л У пользователя есть свой реквест. То как он его описал и результирующее видение ПМа по любому отличается от того, что он хочет. То как систему запроектировал архитектор еще больше уводит все от того, что хочет пользователь. И наконец выходят асы программирования, которые реализуют систему так как увидели они. А если в результате вышло эффективное "не то", то виноват тестер. или архитектор или ПМ или даже юзер который не все сказал. Правда? В результате получаем тупик и переделки эффективного кода.. Целостность и однотипность системы - не пустые слова, а одна из важнейших характеристик. Если управляет один - будет однотипная целостная система. А в твоем случае я не понял, кто и как принимает решения. У нас нет ПМа у нас есть продакт-овнер. Роль ПМ играет вся команда целиком. Проджект менеджер - лишнее звено Расскажи, как у вас разруливаются конфликтные ситуации. к заданному сроку не сделали запланированное. (Кстати, а кем запланированное? Кто выдерживает график работ? Кто контролирует сроки? Вообще сроки стоят?). Как определяете проблемную часть работ и как разруливаете? Особенно не работает, когда заказчик отсутствует это как??? Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах
mmoustaf 101 Жалоба Опубликовано: 11 л А как руководство компании получает понятия о текущем состоянии дел? Каждый программист сам отчитывается? Это или ад, или у вас маленькая компания. сколько человек, если не секрет? Эээ... заказчик получает демонстрацию в конце каждого спринта. Руководство получает отчет на основании бэклога, заказчик тоже. В бэклоге есть то что мы сделали и то, что мы не сделали. А также то. что мы планируем сделать в этом спринте. У тебя как то все факапы случаются внезапно. Вот как раз для случаев задержек, недоработок, неправильной изначальной оценки и существует ПМ. Который все эти вопросы и видит. В том числе вопросы типа "а что, если???" Не у меня. В жизни. В жизни все факапы случатся как обычно внезапно. Более того ПМ, как ключевая точка тоже может внезапно выйти из строя. И команда должна суметь среагипровать именно при внезапном изменении. В наихудшем, то бишь, случае. Расскажи, как у вас разруливаются конфликтные ситуации. к заданному сроку не сделали запланированное. (Кстати, а кем запланированное? Кто выдерживает график работ? Кто контролирует сроки? Вообще сроки стоят?). Как определяете проблемную часть работ и как разруливаете? Игорь ответил. Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах
mmoustaf 101 Жалоба Опубликовано: 11 л Скрам, Скрам, Скрам. Много читаем и ответы приходят сами по мере чтения. Для этого есть, например, Скрам-Мастер. Существуют два принципиально разных вида девелоперов: - Одни ... - Другие ... Вот! Первых я называю быдлопрограммеры. Потому, что это массовый сейчас тип. Про других... Недостатки: таких девелоперов очень мало (мы, например, до сих пор не можем найти нужне количество), они дорогие. ну они дорогие потому, что их мало. И за них бьются, да. У нас кстати в конторе их щас выращивать начали, реально. Ну и набирали тоже таких. Я пошутил У нас у самих Скрам, он отлично работает. Да я понимаю, что пошутил - это больше в аудиторию было. Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах
mmoustaf 101 Жалоба Опубликовано: 11 л Это не всегда работает. Особенно не работает, когда заказчик отсутствует, а аналитика сложная, объёмная и не очень однозначная. Я просто в геймдеве работаю, своя специфика есть. Для нас подход, который я описал выше, здесь работает достаточно хорошо за ооочень редкими исключениями. Если заказчик отсутствует - то продукт никому не нужен. Как ты думаешь для кого вы делаете продукт в геймдеве? Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах
erling9 148 Жалоба Опубликовано: 11 л Если заказчик отсутствует - то продукт никому не нужен. В вашем случае (геймдев) заказчик все равно есть. И кстати в геймдеве скрам работает очень отлично, лучше всего кстати. В геймдеве скрам работает отлично, я и не спорю. Если роль заказчика отдать продюсеру, суть продакту, то да, конечно есть. Заказчик в обычном понимании часто появляется только после появления издателя, что часто бывает на последней трети разработки, которая до этой последней трети должна как-то дойти. Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах
mmoustaf 101 Жалоба Опубликовано: 11 л Если роль заказчика отдать продюсеру, суть продакту, то да, конечно есть. Заказчик в обычном понимании часто появляется только после появления издателя, что часто бывает на последней трети разработки, которая до этой последней трети должна как-то дойти. А кто пользуется продуктом геймдева? Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах