Живучие программы

    Есть у меня приятель, который в свое время написал на работе пару программ. Делал он это, что называется, для души — просто брал и автоматизировал свою деятельность. Поначалу на его работу никто не обращал внимания, мол, ковыряешься и Бог с тобой. Через некоторое время программы стали «расползаться» — приходили люди из соседних отделов, затем из соседних контор и просили поделиться. Где-то через полтора года мы насчитали более 100 инсталляций программы, притом что у нее отсутствовала документация и техподдержка. Это было в 2001 году. В 2002 году приятель поменял область деятельности и перестал заниматься разработкой. Программы разошлись уже в другие регионы, по одной из них была написана дипломная работа. Денег с программ приятель не получил, да и не особо старался.
    Интересное началось в этом году, когда распоряжением головной конторы, расположенной Москве, обе программы были сначала заменены на централизованные, а затем и вообще отключены. По факту оказалось, что практически во всех подразделениях, эксплуатировавших программы моего приятеля, сотрудники заполняли данными обе программы, и московскую, и «свою».
    Отключение продолжалось недолго — одну программу вернули через 3 дня, другую — через две недели. Более того, приятелю хотят заплатить за развитие обеих программ, а одну из них информатизаторам вменили внедрять во всех подразделениях в обязательном порядке.
    Мораль сей басни такова: если программа пишется снизу, от потребности, то люди будут за нее горой и жизнь у нее будет долгая, хотя, быть может, не всегда счастливая. В отличие от программ, насаждаемых сверху, которыми люди пользуются, но зачастую тихо ненавидят.
    Share post

    Similar posts

    Comments 11

      +4
      Это просто привычка.
      Если бы в 2001 году озаботились внедрением программы «сверху», то ей бы и пользовались.
        +1
        Согласен, я уже несколько раз встречался с подобными «живучими программами» которые становились бутылочным горлышком, конечного пользователя с трудом удавалось заставить перейти на что-то другое.
        Поэтому тут все далеко не все так однозначно.
          0
          Согласен, не все одназначно.
          Сам участвовал в разработке/внедрении/выводе из эксплуатации не одного десятка систем и знаю, что такие самописанные системы могут быть узким местом. Но также знаю и то, что крупные enterprise-системы не могут учесть всех тех тонкостей, которые есть у пользователей на местах. Здесь же программы из небольшой наколенной разработки выросли до зрелой системы, да еще и без особого содействия со стороны автора.
          Меня поразило именно это — попадание программиста в потребность и то, что инструмент удался.
            +2
            Не удивительно. Вообще, вы затронули достаточно хорошую тему.
            При подходе «снизу вверх» система оказывается заточенной под имеющиеся в фирме бизнес-процессы. При подходе «сверху вниз» бизнес-процессы приходится подстраивать под систему. По сути глупо пользоваться только одним подходом. У обоих есть как сильные так и слабые стороны.

            Сильная сторона «снизу вверх» — максимальная заточка и интеграция системы в фирме, максимальное удобство и интуитивность использования.
            Слабая сторона подхода «снизу вверх» — многие порочные практики которые существовали в бизнес-процессах фирмы до внедрения, найдя свое отражение в системе становятся очень трудно, практически неизкоренимы.
            Сильная сторона «сверху вниз» — возможность введения в бизнес-процессы чего-то нового, каких-то продвинутых и революционных подходов, которых до этого не было (как например, сканнер штрихкода на складе вместо тетрадки в клеточку).
            Слабая сторона «сверху вниз» — многие сделанные «от большого ума» подходы могут навязывать ненужную и неоправданную ломку существующих бизнес-процессов а иногда и вообще в худшем случае может выступать в роли ошейника, лишающего фирму конкуррентных преимуществ имеющихся ноу-хау текущих бизнес-процессов.

            Удачный бизнес-инструмент представляет как раз очень осознанное сочетание подходов обоих направлений. Кстати, программа у вас удалась, потому что вы следовали своей интуиции, а не пытались бездумно делать «как советуют дяди в умных книжках».

            Так вот, вы сейчас столкнулись с тем, что называется «кризис роста» когда масштаб использования чего-то подошел к необходимости перехода на новый этап. Как раз на этом этапе стоит прикинуть что можно и нужно менять в системе, где и на каких участках какой подход применить. То есть где-то возможно стоит применить «снизу вверх» — то есть отразить какие-то новые особенности бизнес-процессов, а где-то и «сверху вниз» дав системе какие-нибудь дополнительные организующие факторы.
        +2
        Нет ничего более постоянного, чем временное. Нет ничего более временного, чем постоянное.

        Как автор нескольких программ с аналогичной «живучей» судьбой, хочу заметить, что живучесть программы определяется в основном потребностью пользователей и соответствием программы этим потребностям. Качество кода, баги, документация, поддержка, планирование, насаждение сверху — роли играют мало.
        Программа — это инструмент. Если инструмент нужен и работает — им пользуются и косо смотрят на попытки отобрать и заменить.

        Да, привыкание пользователей может представлять проблему. Но не забывайте, что для пользователей переход — это всегда переобучение работе с привычными вещами.
          +1
          > Программа — это инструмент. Если инструмент нужен и работает — им пользуются и косо смотрят на попытки отобрать и заменить.

          Собственно именно эту мысль и хотел донести. В ситуации с моим приятелем программы писались именно как инструмент, который был нужен для работы.
          0
          а что за программа, если не секрет? для чего она?
            0
            Одна — весьма специфичный инструмент по учету неисправностей в электрооборудовании, раскиданном на большом расстоянии, другая — своеобразный органайзер, позволяющий собрать в одно время большое количество народа, также находящегося на большом расстоянии.
            0
            Была у меня программа тоже живучая, но не совсем в том смысле что у автора топика, а просто «жила» она достаточно долго, лет 10-12. После моего увольнения еще лет 8 точно. Это была DOS-овская программа — меню, запускала она программы выгружаясь из памяти, чтоб дать запускаемой DOS-программе максимальный объем памяти. Удобство было в том, что описание меню и код запускаемых батников, лежал на сетевом диске. Написал я ее для экономии своего времени, вместо того чтоб бегать и настраивать ярлычки по всему парку машин, я просто на сетевом диске в файле меню добавлял новый раздел или пункт и описывал там все действия, а работникам просто говорил какой пункт выполнить. Там были и сервисные вещи типа бекапов и запуск антивирусов и т.п. Живучая оказалась программа.
              +2
              А все потому, что ваш друг отлично видел бизнес-процесс с которым приходилось иметь дело и знал все его детали. Именно это залог полезной разработки — понимание дела.
                0
                Спасибо, что напомнил. Погуглил свою юношескую прогу для Бата — приятно, что кто-то где-то до сих пор ей пользуется :)

                Only users with full accounts can post comments. Log in, please.