Очередь пальцев в небо. Всё зависит от задачи, организации работы и погоды на Марсе.
Стороны разработчика софта и эксплуатации софта (часто с доработками) требуют совершенно разных подходов. Разный софт требует разных подходов (для примера можно выполнить мысленный эксперимент сравнивая oracle db, поделку на php и 1С). Кроме того, есть вполне актуальный торгуемый софт, чуть более чем полностью состоящий из легаси кода (тот же oracle db).
Например, даже в рамках одной компании могут быть условия, когда «прима» сильно мешает или наоборот, эффективно спасает проект (особенно, если техническая цена спасения проекта не особо важна). Впрочем, по каждому типу разработчика в этой классификации я могу привести как подтверждающий, так и опровергающий пример (видимо, как и большинство реально практикующих управленцев в ит).
Впрочем, статья хорошо написана и неплохо переведена. Как развлекательное чтиво, которое к тому же заставляет немного подумать — отлично.
В большинстве проектов основной риск — в целеполагании, выборе/выделении ресурсов и контроле. Пока эти проблемы не решаются, любой алгоритм управления менее значимыми рисками вносит эффект на пределе погрешности измерения.
Да, все описанные ситуации неприятные. Но в большинстве случаев альтернатива еще хуже. Нередко — гораздо хуже.
Единая БД, которую трудно изменить. А какая альтернатива? Множество БД для каждого приложения не просто хуже, а невыносимо хуже. Использование объектного нароста на БД ломает всю существующую автоматизацию плюс порождает практически нерешаемые проблемы производительности и совместимости. Конечно, можно грамотно спроектировать БД и описать процедуры изменения и синхронизации данных, но при таком подходе никто не ощущает проблемы и трудно обосновать категорическую необходимость модных технологий.
Зависимость от конкретного софта, вендор которого не хочет делать все безумные хотелки заказчика. Альтернатива — доработка софта своими или аутсорсинговыми силами. Вот после нескольких лет такой доработки и нескольких смен команд сладкие дни работы с одним вендором будут пределом мечтаний.
Зависимость от кода проверяется хотя бы статически. А проблемы с миллионом rest микросервисов не протестировать никаким способом. И проблема версионирования микросервисов в практике эксплуатации более проблематична (хотя бы потому, что существенная часть проблем вылезет не при сборке или тестах, а только при продакшене). Собственно, проблема существует еще с мейнфреймов (rpc, ipc и пр.), придумано, реализовано и забыто множество технологий, но принципиального решения все еще нет и даже не предполагается.
Про ETL для бизнес правил vs кодирование бизнес логики даже говорить не надо. Либо спецпрограммисты от бизнеса, либо спецпрограммисты для бизнеса. Разницы никакой. Сложные задачи, что характерно, обычно не имеют простых решений. Вспомним, например, что SQL создавался как простой пользовательский язык управления данными.
Контроль изменений в базе нормально работает только организационно. Причем неважно как внесены изменения — через sql или стандартную форму программы.
Но для этого надо выстраивать диалог с клиентами и выверку данных в своих системах. Это непросто и довольно дорого. Большинство компаний (от банков до гуглов) ограничивается юридическими отмазками своего самоуправства.
А как относятся облака к патчам, например, прикладного софта? или бэкофисного? Никак не относятся, это разные задачи. Проблемы с безопасностью у прикладного софта как бы не более распространены, чем у системного. Патчить, наверно, надо. Но редко какая эксплуатация уязвимости по ущербу способна сравнится с кривым патчем, накатанным в пятницу вечером перед длительными праздниками.
Не говоря уже о проблемах с оборудованием после установки апдейтов firmware (в этом случае не напрасно есть золотое правило: работает — не трогай).
Значимость патчей для безопасности сильно преувеличена, особенно для бэкофисного оборудования (недоступного напрямую из интернета или относительно публичных сегментов). Организационные меры важнее на порядок, а иногда на два порядка.
А вот для бизнеса простои и проблемы из-за патчей несут прямой убыток, иногда очень значительный. Так что всё правильно делают. А некоторые патчи или обновления версия полезно выдерживать месяцами, если не годами (некоторые обновление СУБД или серверов приложений).
Шикарно. Позвать консультанта, который на своем птичьем языке объяснил элементарную культуру делового взаимодействия.
Впрочем, возможно это правильно. Мне всегда казалось, что практику делового общения вырабатывает реальная работа, преимущественно в крупной организации. Но раз таких людей в малых компаниях нет или их опыт не используют, то консультант — меньшее зло (хотя все равно зло — денег стоит, причем обычно говорит очевидные вещи из книжки). Обучение новых сотрудников лучше, но скорее дороже и компании обычно не хотят вкладываться в людей.
Полезное правило в документации: за деепричастный оборот расстрел на месте, предложение с тремя запятыми и более — штраф или объяснительная. Вообще, писать надо как для слегка умственно отсталого. Лучше повториться, чем допустить неясность. Вообще, красота текста документации — зло, требуется невозможность неправильного толкования.
А вы тоже используете две джиры, одну для разработчиков, другую для заказчиков? ;)
Не джиру и не две, но мысль пошла в этом направлении ;-)
Книга Брукса это список проблем нежели решений, более того, сам Брукс систематизировал их в список из двух сотен утверждений требующих критики.
Наверно вы правы. Я читал книгу довольно давно, и в памяти остались именно варианты решений проектных вопросов. Возможно, это было додумано мною при чтении, возможно, какие-либо ответы в книге есть. Собственно, даже если то, что осталось в памяти, это моё понимание вопросов, поднятых в книге, то книга свою задачу полностью выполнила — стимулировала мышление.
Есть вопросы, который каждый управленец открывает для себя сам. Это вопросы с сакральным смыслом, искать консенсус по ним бессмысленно (и правильного ответа на эти вопросы просто нет):
— Надо ли все проекты вести по одной методологии?
— Должен ли менеджер быть специалистом?
— Кнут или пряник?
— Точное планирование или главное ввязаться?
— Эджайлый скрам наше все или нет?
— Можно ли ядро банковский системы написать на php?
— И пр.
(Вопроса, надо ли врать заказчику при оценке проекта я не пишу, поскольку очевидно, что врать).
У Брукса на подобные вопросы дан какой-либо ответ. С этим ответом можно соглашаться или нет, это ничего не меняет. Вообще, такие производственные мемуары нужны чтобы задуматься, а не искать ответ. В конце концов, можно вылепить Апполона из пенопласта ножовкой по металлу, но в программных проектах трудно сказать, какой метод работы правильный, а какой анекдотичен (предполагаю, что очень много программных проектов сделаны таким методом, просто им повезло).
Надо сравнивать сравнимые показатели. OS/360 — пример первого Enterprise программного продукта. И сравнивать его надо с такими же крупными промышленными решениями. Так вот, в таких решениях изменилось мало что за эти десятилетия. Так же невозможно точно планировать, так же сложно управлять огромным коллективом, так же есть проблема обманутых ожиданий и т.п.
Спринты на 2 недели — отличное решение для небольших или архитектурно простых проектов. Или для наращивания функционала в крупном сложном проекте после стабилизации основных механизмов. Но для разработки этих самых основных механизмов требуется другой подход. И работа с крупным клиентом с тысячами требований радикально отличается от работы с клиентом с десятками требований.
Если мы говорим про один и тот же тетрис, то можно выкинуть в этом тетрисе строку копирайта и таблицу рекордов и ничего сложного. Но с таблицей рекордов есть фича — уложиться максимально близко к 64К-1, что тоже один из челленджей, так что такое выкидывание заметно меняет использование.
только pipe периодически забивается и приходится использовать метод: dbms_pipe.purge
Надо использовать при открытии pipe параметр maxpipesize с адекватным значением и не забывать выбирать из pipe все сообщения. И ничего забиваться не будет.
В итоге у вас получился довольно громоздкий и не особо прозрачный уникальный генератор отчетов.
С заметным порогом вхождения. Но почти вся реальная гибкость — в возможности привязать plsql процедуру.
При это есть куча неочевидных кнопок, какие то странные аббревиатуры (COU_D), слова на басурманском (2 desc).
И все равно программизм прорывается (Параметр №2 Varchar_250).
Как писали выше, есть вполне удачные стандартные средства (Jasper Reports, например). Продуманные, испытанные временем, с документацией, по котором есть чего погуглить.
После неоднократных звонков в поддержку провайдера и аналогичных контор я вывел для себя правило успеха: никогда не показывать свое понимание. Надо говорить не «у меня x.x.x.x не пингуется», а «не могу открыть сайт», не «у вас наверно сбойнул роутер после скачка питания», а «интернет не работает». При таком подходе повышается шанс, что либо скрипт оператора нормально сработает и проблема решится, либо быстрее переключат на специалиста, где знания скрывать не надо (но придерживать свою гениальность полезно, чтобы у специалиста с «той стороны» не возник приступ неконтролируемой ярости).
Стороны разработчика софта и эксплуатации софта (часто с доработками) требуют совершенно разных подходов. Разный софт требует разных подходов (для примера можно выполнить мысленный эксперимент сравнивая oracle db, поделку на php и 1С). Кроме того, есть вполне актуальный торгуемый софт, чуть более чем полностью состоящий из легаси кода (тот же oracle db).
Например, даже в рамках одной компании могут быть условия, когда «прима» сильно мешает или наоборот, эффективно спасает проект (особенно, если техническая цена спасения проекта не особо важна). Впрочем, по каждому типу разработчика в этой классификации я могу привести как подтверждающий, так и опровергающий пример (видимо, как и большинство реально практикующих управленцев в ит).
Впрочем, статья хорошо написана и неплохо переведена. Как развлекательное чтиво, которое к тому же заставляет немного подумать — отлично.
Единая БД, которую трудно изменить. А какая альтернатива? Множество БД для каждого приложения не просто хуже, а невыносимо хуже. Использование объектного нароста на БД ломает всю существующую автоматизацию плюс порождает практически нерешаемые проблемы производительности и совместимости. Конечно, можно грамотно спроектировать БД и описать процедуры изменения и синхронизации данных, но при таком подходе никто не ощущает проблемы и трудно обосновать категорическую необходимость модных технологий.
Зависимость от конкретного софта, вендор которого не хочет делать все безумные хотелки заказчика. Альтернатива — доработка софта своими или аутсорсинговыми силами. Вот после нескольких лет такой доработки и нескольких смен команд сладкие дни работы с одним вендором будут пределом мечтаний.
Зависимость от кода проверяется хотя бы статически. А проблемы с миллионом rest микросервисов не протестировать никаким способом. И проблема версионирования микросервисов в практике эксплуатации более проблематична (хотя бы потому, что существенная часть проблем вылезет не при сборке или тестах, а только при продакшене). Собственно, проблема существует еще с мейнфреймов (rpc, ipc и пр.), придумано, реализовано и забыто множество технологий, но принципиального решения все еще нет и даже не предполагается.
Про ETL для бизнес правил vs кодирование бизнес логики даже говорить не надо. Либо спецпрограммисты от бизнеса, либо спецпрограммисты для бизнеса. Разницы никакой. Сложные задачи, что характерно, обычно не имеют простых решений. Вспомним, например, что SQL создавался как простой пользовательский язык управления данными.
Но для этого надо выстраивать диалог с клиентами и выверку данных в своих системах. Это непросто и довольно дорого. Большинство компаний (от банков до гуглов) ограничивается юридическими отмазками своего самоуправства.
Не говоря уже о проблемах с оборудованием после установки апдейтов firmware (в этом случае не напрасно есть золотое правило: работает — не трогай).
А вот для бизнеса простои и проблемы из-за патчей несут прямой убыток, иногда очень значительный. Так что всё правильно делают. А некоторые патчи или обновления версия полезно выдерживать месяцами, если не годами (некоторые обновление СУБД или серверов приложений).
Впрочем, возможно это правильно. Мне всегда казалось, что практику делового общения вырабатывает реальная работа, преимущественно в крупной организации. Но раз таких людей в малых компаниях нет или их опыт не используют, то консультант — меньшее зло (хотя все равно зло — денег стоит, причем обычно говорит очевидные вещи из книжки). Обучение новых сотрудников лучше, но скорее дороже и компании обычно не хотят вкладываться в людей.
Не джиру и не две, но мысль пошла в этом направлении ;-)
Наверно вы правы. Я читал книгу довольно давно, и в памяти остались именно варианты решений проектных вопросов. Возможно, это было додумано мною при чтении, возможно, какие-либо ответы в книге есть. Собственно, даже если то, что осталось в памяти, это моё понимание вопросов, поднятых в книге, то книга свою задачу полностью выполнила — стимулировала мышление.
— Надо ли все проекты вести по одной методологии?
— Должен ли менеджер быть специалистом?
— Кнут или пряник?
— Точное планирование или главное ввязаться?
— Эджайлый скрам наше все или нет?
— Можно ли ядро банковский системы написать на php?
— И пр.
(Вопроса, надо ли врать заказчику при оценке проекта я не пишу, поскольку очевидно, что врать).
У Брукса на подобные вопросы дан какой-либо ответ. С этим ответом можно соглашаться или нет, это ничего не меняет. Вообще, такие производственные мемуары нужны чтобы задуматься, а не искать ответ. В конце концов, можно вылепить Апполона из пенопласта ножовкой по металлу, но в программных проектах трудно сказать, какой метод работы правильный, а какой анекдотичен (предполагаю, что очень много программных проектов сделаны таким методом, просто им повезло).
Спринты на 2 недели — отличное решение для небольших или архитектурно простых проектов. Или для наращивания функционала в крупном сложном проекте после стабилизации основных механизмов. Но для разработки этих самых основных механизмов требуется другой подход. И работа с крупным клиентом с тысячами требований радикально отличается от работы с клиентом с десятками требований.
Надо использовать при открытии pipe параметр maxpipesize с адекватным значением и не забывать выбирать из pipe все сообщения. И ничего забиваться не будет.
С заметным порогом вхождения. Но почти вся реальная гибкость — в возможности привязать plsql процедуру.
При это есть куча неочевидных кнопок, какие то странные аббревиатуры (COU_D), слова на басурманском (2 desc).
И все равно программизм прорывается (Параметр №2 Varchar_250).
Как писали выше, есть вполне удачные стандартные средства (Jasper Reports, например). Продуманные, испытанные временем, с документацией, по котором есть чего погуглить.