Очень показательный пример создания решения с неверными целевыми ориентирами. Любопытно, что среди прочих выводов, не было попыток сделать основной, наиболее интересный для программиста — как же создавать такие системы правильным образом?
Одна из (а может и единственная по своей сути) найденных формулировок цели по тексту:
Я снова хочу знать, кто тот засранец, не принимающий задачу в работу. Я хочу четко видеть, где та гадина, не проверяющая и не принимающая результат выполненной программистом работы.
Это вообще возможно, если деструктивной элемент не единственный в организации?
Чего не хватает:
* оценка эффективности работы организации выраженный в объеме производства или в денежном эквиваленте.
* типизация задач (по тексту было обозначено подозрение на постановку, частично — как раз оно). Должна отражать связь с… пусть будет бизнес целью. Т.е. быть частью существующей задачи/процесса польза которой очевидна.
Тогда, полагаю, станет возможным выявление слабых элементов посредством отчетности в разрезе задач: количество и процент на функциональную еденицу, средняя длительность для различных типов, аномалии выраженные в чрезмерном количество и т.д… Правильная оценка которой должна условно делить людей на 2 группы…
Точку зрения автора легко принять, разработка во все времена плохо переваривала менеджеров, в этом нет ничего удивительного. Похоже, само определение на протяжении статьи взято в кавычки по причине отсутствия понимания, какой менеджер может быть хорошим или плохим в контексте существующей проблемы. И, таким образом, выставляя в плохом свете и тех и других.
Есть такая старая добрая книга, называется Code Complete. В ней дается хорошее представление о том, чем по своей сути является создание продукта. Её вроде как многие читают, если не все, но похоже что полезное из неё выносят лишь еденицы. Кто-нибудь помнит чтобы в ней уделялось внимание менеджменту?
Набыдлокодили, выстрелило, и теперь не знаем что делать? Процесс внесения изменений в код багоёмкий и занимает слишком много времени? — Никакой менеджмент это не исправит. Использование методологий, автотестов, технологий, паттернов — это может разрешить часть проблем, если есть понимание зачем это нужно, но фундаментальным такое решение не будет.
Если нет понимания продукта на должном уровне, вряд ли возможно построить по настоящему качественное решение. Архитектура — не забыли еще такое слово? Она структурирует/определяет процесс разработки в рамках существующих требований (не менеджеры), упрощает реализацию типовых задач, переводит в плоскость компоновки лаконичных сущностей. Она может быть не везде нужна, но если возникают проблемы, послужившие началом появления этой статьи, то определенно потому что ей не уделяется должное внимание.
Одна из (а может и единственная по своей сути) найденных формулировок цели по тексту:
Это вообще возможно, если деструктивной элемент не единственный в организации?
Чего не хватает:
* оценка эффективности работы организации выраженный в объеме производства или в денежном эквиваленте.
* типизация задач (по тексту было обозначено подозрение на постановку, частично — как раз оно). Должна отражать связь с… пусть будет бизнес целью. Т.е. быть частью существующей задачи/процесса польза которой очевидна.
Тогда, полагаю, станет возможным выявление слабых элементов посредством отчетности в разрезе задач: количество и процент на функциональную еденицу, средняя длительность для различных типов, аномалии выраженные в чрезмерном количество и т.д… Правильная оценка которой должна условно делить людей на 2 группы…
Есть такая старая добрая книга, называется Code Complete. В ней дается хорошее представление о том, чем по своей сути является создание продукта. Её вроде как многие читают, если не все, но похоже что полезное из неё выносят лишь еденицы. Кто-нибудь помнит чтобы в ней уделялось внимание менеджменту?
Набыдлокодили, выстрелило, и теперь не знаем что делать? Процесс внесения изменений в код багоёмкий и занимает слишком много времени? — Никакой менеджмент это не исправит. Использование методологий, автотестов, технологий, паттернов — это может разрешить часть проблем, если есть понимание зачем это нужно, но фундаментальным такое решение не будет.
Если нет понимания продукта на должном уровне, вряд ли возможно построить по настоящему качественное решение. Архитектура — не забыли еще такое слово? Она структурирует/определяет процесс разработки в рамках существующих требований (не менеджеры), упрощает реализацию типовых задач, переводит в плоскость компоновки лаконичных сущностей. Она может быть не везде нужна, но если возникают проблемы, послужившие началом появления этой статьи, то определенно потому что ей не уделяется должное внимание.