Comments 11
Это просто привычка.
Если бы в 2001 году озаботились внедрением программы «сверху», то ей бы и пользовались.
Если бы в 2001 году озаботились внедрением программы «сверху», то ей бы и пользовались.
Согласен, я уже несколько раз встречался с подобными «живучими программами» которые становились бутылочным горлышком, конечного пользователя с трудом удавалось заставить перейти на что-то другое.
Поэтому тут все далеко не все так однозначно.
Поэтому тут все далеко не все так однозначно.
Согласен, не все одназначно.
Сам участвовал в разработке/внедрении/выводе из эксплуатации не одного десятка систем и знаю, что такие самописанные системы могут быть узким местом. Но также знаю и то, что крупные enterprise-системы не могут учесть всех тех тонкостей, которые есть у пользователей на местах. Здесь же программы из небольшой наколенной разработки выросли до зрелой системы, да еще и без особого содействия со стороны автора.
Меня поразило именно это — попадание программиста в потребность и то, что инструмент удался.
Сам участвовал в разработке/внедрении/выводе из эксплуатации не одного десятка систем и знаю, что такие самописанные системы могут быть узким местом. Но также знаю и то, что крупные enterprise-системы не могут учесть всех тех тонкостей, которые есть у пользователей на местах. Здесь же программы из небольшой наколенной разработки выросли до зрелой системы, да еще и без особого содействия со стороны автора.
Меня поразило именно это — попадание программиста в потребность и то, что инструмент удался.
Не удивительно. Вообще, вы затронули достаточно хорошую тему.
При подходе «снизу вверх» система оказывается заточенной под имеющиеся в фирме бизнес-процессы. При подходе «сверху вниз» бизнес-процессы приходится подстраивать под систему. По сути глупо пользоваться только одним подходом. У обоих есть как сильные так и слабые стороны.
Сильная сторона «снизу вверх» — максимальная заточка и интеграция системы в фирме, максимальное удобство и интуитивность использования.
Слабая сторона подхода «снизу вверх» — многие порочные практики которые существовали в бизнес-процессах фирмы до внедрения, найдя свое отражение в системе становятся очень трудно, практически неизкоренимы.
Сильная сторона «сверху вниз» — возможность введения в бизнес-процессы чего-то нового, каких-то продвинутых и революционных подходов, которых до этого не было (как например, сканнер штрихкода на складе вместо тетрадки в клеточку).
Слабая сторона «сверху вниз» — многие сделанные «от большого ума» подходы могут навязывать ненужную и неоправданную ломку существующих бизнес-процессов а иногда и вообще в худшем случае может выступать в роли ошейника, лишающего фирму конкуррентных преимуществ имеющихся ноу-хау текущих бизнес-процессов.
Удачный бизнес-инструмент представляет как раз очень осознанное сочетание подходов обоих направлений. Кстати, программа у вас удалась, потому что вы следовали своей интуиции, а не пытались бездумно делать «как советуют дяди в умных книжках».
Так вот, вы сейчас столкнулись с тем, что называется «кризис роста» когда масштаб использования чего-то подошел к необходимости перехода на новый этап. Как раз на этом этапе стоит прикинуть что можно и нужно менять в системе, где и на каких участках какой подход применить. То есть где-то возможно стоит применить «снизу вверх» — то есть отразить какие-то новые особенности бизнес-процессов, а где-то и «сверху вниз» дав системе какие-нибудь дополнительные организующие факторы.
При подходе «снизу вверх» система оказывается заточенной под имеющиеся в фирме бизнес-процессы. При подходе «сверху вниз» бизнес-процессы приходится подстраивать под систему. По сути глупо пользоваться только одним подходом. У обоих есть как сильные так и слабые стороны.
Сильная сторона «снизу вверх» — максимальная заточка и интеграция системы в фирме, максимальное удобство и интуитивность использования.
Слабая сторона подхода «снизу вверх» — многие порочные практики которые существовали в бизнес-процессах фирмы до внедрения, найдя свое отражение в системе становятся очень трудно, практически неизкоренимы.
Сильная сторона «сверху вниз» — возможность введения в бизнес-процессы чего-то нового, каких-то продвинутых и революционных подходов, которых до этого не было (как например, сканнер штрихкода на складе вместо тетрадки в клеточку).
Слабая сторона «сверху вниз» — многие сделанные «от большого ума» подходы могут навязывать ненужную и неоправданную ломку существующих бизнес-процессов а иногда и вообще в худшем случае может выступать в роли ошейника, лишающего фирму конкуррентных преимуществ имеющихся ноу-хау текущих бизнес-процессов.
Удачный бизнес-инструмент представляет как раз очень осознанное сочетание подходов обоих направлений. Кстати, программа у вас удалась, потому что вы следовали своей интуиции, а не пытались бездумно делать «как советуют дяди в умных книжках».
Так вот, вы сейчас столкнулись с тем, что называется «кризис роста» когда масштаб использования чего-то подошел к необходимости перехода на новый этап. Как раз на этом этапе стоит прикинуть что можно и нужно менять в системе, где и на каких участках какой подход применить. То есть где-то возможно стоит применить «снизу вверх» — то есть отразить какие-то новые особенности бизнес-процессов, а где-то и «сверху вниз» дав системе какие-нибудь дополнительные организующие факторы.
Нет ничего более постоянного, чем временное. Нет ничего более временного, чем постоянное.
Как автор нескольких программ с аналогичной «живучей» судьбой, хочу заметить, что живучесть программы определяется в основном потребностью пользователей и соответствием программы этим потребностям. Качество кода, баги, документация, поддержка, планирование, насаждение сверху — роли играют мало.
Программа — это инструмент. Если инструмент нужен и работает — им пользуются и косо смотрят на попытки отобрать и заменить.
Да, привыкание пользователей может представлять проблему. Но не забывайте, что для пользователей переход — это всегда переобучение работе с привычными вещами.
Как автор нескольких программ с аналогичной «живучей» судьбой, хочу заметить, что живучесть программы определяется в основном потребностью пользователей и соответствием программы этим потребностям. Качество кода, баги, документация, поддержка, планирование, насаждение сверху — роли играют мало.
Программа — это инструмент. Если инструмент нужен и работает — им пользуются и косо смотрят на попытки отобрать и заменить.
Да, привыкание пользователей может представлять проблему. Но не забывайте, что для пользователей переход — это всегда переобучение работе с привычными вещами.
а что за программа, если не секрет? для чего она?
Была у меня программа тоже живучая, но не совсем в том смысле что у автора топика, а просто «жила» она достаточно долго, лет 10-12. После моего увольнения еще лет 8 точно. Это была DOS-овская программа — меню, запускала она программы выгружаясь из памяти, чтоб дать запускаемой DOS-программе максимальный объем памяти. Удобство было в том, что описание меню и код запускаемых батников, лежал на сетевом диске. Написал я ее для экономии своего времени, вместо того чтоб бегать и настраивать ярлычки по всему парку машин, я просто на сетевом диске в файле меню добавлял новый раздел или пункт и описывал там все действия, а работникам просто говорил какой пункт выполнить. Там были и сервисные вещи типа бекапов и запуск антивирусов и т.п. Живучая оказалась программа.
А все потому, что ваш друг отлично видел бизнес-процесс с которым приходилось иметь дело и знал все его детали. Именно это залог полезной разработки — понимание дела.
Спасибо, что напомнил. Погуглил свою юношескую прогу для Бата — приятно, что кто-то где-то до сих пор ей пользуется :)
Sign up to leave a comment.
Живучие программы