Проекты разработки компьютерных приложений. Особенности

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

    Нужно очень хорошо понимать отличие этих проектов от остальных и особенно от проектов внедрения компьютерных приложений в бизнес-процессы организации.

    Существует два риска, которые очень часто выливаются в проблемы:

    1. те кто специализируется на разработке ПО, не замечает как ступают на территорию внедрения и проект начинает надуваться… как правило с летальным исходом;

    2. те кто специализируются на внедрении и организационных проектах, без понимания сложности, начинают разработку и качество результатов начинает существенно падать — и это в лучшем случае;

    Для тех кто занимается чистым внедрением или чистой разработкой — эти проблемы неведомы. Но это редкие счастливчики.

    Уходим в детали…

    Отличительные особенности


    Для начала давайте разберем критерии, по которым мы можем отличить проект разработки компьютерных приложений:

    1. результатом такого проекта является компьютерное приложение (web, windows, android, iOS …), модуль (функциональный блок) или какое-то существенное изменение (что такое «существенное изменение» — разберем ниже);

    2. эти проекты требуют глубоких знаний архитектуры компьютерных приложений и соответствующего стека технологий, но при этом подразумевают минимальное взаимодействие с пользователями или сотрудниками задействованных в каких-либо бизнес-процессах.

    п.2 — в части «мало затрагивают взаимодействие с пользователями» — это ключевая особенность, отличающая проект разработки компьютерного приложения от проекта внедрения компьютерного приложения в бизнес-процессы. Это не значит что такого взаимодействия нет, конечно же есть, просто оно минимально.

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

    Существенные изменения


    Отдельной подкатегорией можно выделить проекты, которые стоит запускать, когда речь заходить о группе изменений, объединенных одной целью, которые могут длиться продолжительное время и затрагивать несколько версий (релизов).

    Если изменение или группа изменений помещается в один релиз — затевать проект не стоит.

    Но если одно изменение, тянет за собой серию других изменений, вот тут уже стоит задуматься о запуске проекта, потому что:

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

    2. Одно изменение может потянуть за собой изменения других механизмов системы, это вызывает различные риски, которые также нужно учитывать и быть к ними готовыми — лучше всего это делать через проектное управление

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

    Например:

    В системе управления задачами, нужно было расширить блок Участники. Добавить возможность выбора не только сотрудников, но и группы

    — Начали с проработки интерфейса, оказалось что нужно менять подсистему доступа

    — Начали менять подсистему доступа, поняли что нужно оставить старую на некоторое время, потому рядом создали новый механизм, без ломки старого

    — Внесли изменения в интерфейс, подружили с новой моделью, отладили новый

    — Теперь нужно удалить старый механизм

    Все 4 пункта — растянулись на 5 месяцев и 3 версии разработки. Без координации — было бы на много дольше, а в результате могли бы просто потерять вектор цели и забыть про то что старый механизм нужно удалить.

    Опасный момент


    Очень опасной, но также и крайне распространенной является ситуация, когда заказчик просит разработать некую систему: учет финансов, работа менеджеров по продажам или что-то типа того.

    Вроде бы с первого взгляда это обычный проект разработки. Нужно что-то разработать.

    Но шансов на успех у этого проекта не много, т.к. очень скоро окажется что приложение готово, но заказчик почему то не доволен. Система не работает.

    Причина в том, что внедрение — это отдельная область знаний. А проекты внедрения — это отдельная категория проектов.

    Автор долгое время специализировался именно на этих проектах, и все это время не верил в существование проектов разработки компьютерных приложений.

    Долгое время мне удавалось реализовывать различные ИТ-проекты, лишь краем затрагивая разработку. Это вызывало дикие проблемы, потому старался всегда разработчиков обходить стороной. Лучше внедрить типовой продукт типа 1С УПП 8, а после чего можно дорабатывать. И это вполне реально, хоть многие 1С-разработчики в это не очень то верят

    Итого


    Однако за последний год меня угораздило мне повезло заниматься проектами внедрения, вплотную завязанным на проекты разработки. Это был крайне тяжелый год.

    После чего выработались те определения, которые вы прочитали в начале статьи.

    Наверное для разработчиков приложений — я не открыл ничего нового. Те кто сидят за стенкой из Интернет в далеке от конечных пользователей — занимаются только проектами разработки компьютерных приложений — все это понятно как ясень день.

    Но вот те кто работают в отделах ИТ различных организаций, вот для них это все суровые «трудовыебудни».

    Готов поспорить, что в большинстве организаций нет таких процессов:

    1. управление проектами разработки

    2. управление релизами

    3. управление изменениями по релизам

    Хоть практика ITIL и говорит что они нужны, но многие этими рекомендациями пренебрегают. Или попытались, но не получилось.

    Мне чаще приходится иметь дело с проектами внедрения, но за этот год пришлось углубиться в тему разработки и поставить вышеперечисленные процессы на поток.

    Что заметил?

    1. проще стало прогнозировать ресурсы и затраты на развитие информационной системы

    2. у разработчиков больше позитива в работе, когда закрываешь не просто изменение или релиз, а целый проект, который целенаправленно вели и коорденировали долгое время

    3. особенно хорошо, когда проект закрывает сам разработчик. Это уже не мелкое изменение — это уже проект. Совсем другие ощущения.

    4. ну и конечно же качество разработки — хвосты не теряются, серии изменений проходят точнее и с меньшими ошибками

    5. на сколько удалось понять, в SCRUM — аналогом проекта является «запрос» или «заказ», который может поступить от «Заказчика», и который затем нужно разбить на задачи, которые могут закрываться в разных релизах.

    А какой у вас опыт внедрения рекомендаций ITIL? И как вы определяется проект разработки компьютерных приложений? Отличаете ли их от проектов внедрения?
    Share post
    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More
    Ads

    Comments 10

      +1
      Если в организации можно внедрить типовую УПП без доработок, то скорее всего им вообще не нужно УПП и можно обойтись чем-нибудь подешевле.
        0
        Я не говорю что такие проекты нужно закрывать вообще без доработки. Если опыта хватает — можно.
        Но 1С УПП — это относительно зрелый продукт. А преимущество зрелых продуктов в том что их можно внедрять без доработки. Да, это будет не так «удобно», с точки зрения пользователя. Но зато меньше рисков. Рисков, когда проект вылетает за все мыслимые бюджет и сроки.
        Думаю мы не будем спорить о том что большая часть проектов внедрения 1С УПП провальны? + затягиваются на годы.
        Для себя выработал вот такие правила. Поделился точкой зрения.

        Если есть другие решения — ссылочку пожалуйста. С удовольствием почитаю.
        0
        >> Но 1С УПП — это относительно зрелый продукт. А преимущество зрелых продуктов в том что их можно внедрять без доработки.
        Спорный тезис. Бизнес-процессы настолько разные бывают на различных отраслях и предприятиях, что серебряную пулю для них для всех никак не подберешь. С ходу могу сказать, что без надстроек (или доработок) УПП непригодна для торговли алкоголем или медикаментами. В нашем случае не хватает функционала для нормального управление ЖКХ.
        Соглашусь только с тем, что всё что можно сделать без доработок лучше делать типовыми механизмами и чем опытнее сотрудники, тем меньше они будут уродовать то, что уже имеется.

        >> Думаю мы не будем спорить о том что большая часть проектов внедрения 1С УПП провальны?
        Я не располагаю статистикой по провальным проектам

        >>+ затягиваются на годы.
        Бывает. Но обычно и объемы работы немаленькие в таких случаях

        >> Если есть другие решения — ссылочку пожалуйста. С удовольствием почитаю.
        Комплексная автоматизация, например, если нет производства. Либо связка УТ+БП+ЗУП. Либо связка УТ+розница+БП+ЗУП. БП и ЗУП остаются типовыми, УТ подстраивается под бизнес-процессы компании. Многим этого за глаза хватает.
          0
          1. Это зависит от целей проекта. Если вы хотите все бизнес процессы завязать в УПП — да, придется много дорабатывать. Но это и поднимает затраты, а также начинает зашкаливать риски.
          Лично я придерживаюсь такой идеи, что УПП — это все то что связано с деньгами. Какие то обслуживающие бизнес-процессы стараюсь в нее не пихать. Для этого есть более удобные приложения, которые легко интегрировать с БП, КА или УПП. Без внесения изменений в конфигурацию 1С.
          2. Я располагаю статистикой, т.к. есть большой опыт работы как на предприятиях, так и в консалтинге, где пришлось повстречаться с убитыми проектами внедрения. Печальное зрелище.
          3. Объем работы не маленький — это следствие ошибочных решений. У меня есть опыт внедрения 1С КА 8, за 3 месяца почти в одного, там где до меня целая бригада программистов трудилась более года и не смогли довести проект до результата.
          4. Ссылочки имелись ввиду на решения по управлению такими проектами, а не 1С-приложения. С ними хорошо знаком :)
          0
          1.>> Для этого есть более удобные приложения, которые легко интегрировать с БП, КА или УПП. Без внесения изменений в конфигурацию 1С.
          Например?

          3. А еще бывает чудесная бюрократия работает. Как недавно, например, для внедрения управленческой зарплаты в ЗУП неделю потребовалось на мелкие доработки, неделю на тестирование и почти пол года на обход бюрократии и саботажа пользователей.

          4. Для управления подойдет что угодно, куда можно написать задачи и отметить этап выполнения. Хоть в блокноте набрать ТЗ, распечатать и маркером отмечать что готово. У нас мегаплан используется в основном. Или я опять не правильно понял вопрос?

          p.s. опять промахнулся с ответом(
            0
            1. Нужен пример проекта. А так пальцем в небо сложно попасть. Если это медикаменты — 1С Розница Аптека. Могу ошибаться.
            Если это ЖКХ, то любая система для документооборота, например ДИРЕКТУМ.
            Даже если это строительные проекты, есть специальная 1С УПП для строительства. В любом случае лучше применять что-то готовое, чем изобретать самому.
            Если это крайне сложный и запущенный случай, то в любом случае я бы не рискнул править конфигурацию сложного 1С-приложения. Лучше взять что-то, что изначально заточено под такие правки. Например CasePress. Там любые настройки модуля не трогают ядро или другие модули. Обновление ядра или компонента — не затрагивает другие компоненты и может проходить автономно.
            Если вы правите 1С УПП, то с выходом новой готовьтесь к пляскам с обновлением. И потратить на это как правило приходится круглую сумму или оставаться без обновления. Такова специфика финансового учета в России.
            2. Бывает. Просто если взять проблему 1 и прибавить проблему 2, то произойдет перемножение проблем :) А зачем? Минус одна проблема — в разы проще реализовать проект.
            4. Мегаплан как раз хорошо подходит для внедрений. Пока не идет речи о разработке. Наладить нормально процесс разработки в Мегаплане крайне сложно. Сами Мегаплановцы свою разработку ведут в другом продукте. И даже тех поддержку ведут в другом продукте.

            А если мы имеем дело со сложными проектам, то управление процессами и проектами в единой среде — очень облегчает жизнь. У меня лично есть опыт создания подобной системы на базе CasePress. Приложение построено по идеологии ACM, позволяет легко адаптироваться под любые бизнес процессы любой сложности и взаимоувязывать их.

            При этом если у меня встанет вопрос с финансовым учетом или зарплатой — я лучше возьму 1С, но постараюсь ее не изменять :) Или изменять но как то по минимуму.
              0
              1С аптека для розничной торговли. Для оптовой 1.5 года назад мы не нашли готовое решение. В ЖКХ есть заморочки с лицевыми счетами, пенями, отчетами агентов и показаниями счетчиков, лучше посмотреть в сторону 1С управление ЖКХ.
              С трудом представляю как надстройку для wordPress можно использовать вместо 1С в плане учета финансов или какого-нибудь замороченного складского учета.
                0
                Я тоже с трудом представляю. И даже писал об этом вот тут habrahabr.ru/post/177235/#comment_6159163
                > Лично я придерживаюсь такой идеи, что УПП — это все то что связано с деньгами.

                В остальном — я не настаиваю на том что моя идея правильная. Хотел лишь выяснить кто и какие еще идеи использует.
                Наш спор ушел в холивар ни о чем. Вы не читаете мои комментарии и начинает спорить сами с собой на тему домыслов из своей же головы.

                В таком случае я ничего не смогу до вас донести. Извините.

                Предлагаю закрыть тему.
                  0
                  >>Я тоже с трудом представляю. И даже писал об этом вот тут habrahabr.ru/post/177235/#comment_6159163
                  Я просто не понял к чему вы привели CasePress в контексте вопроса про то, чем можно заменить 1С. Как по мне так это вообще 2 слабосвязанные сущности. Под бизнес-процессами я имел ввиду не объект конфигурации, а скорее процессы происходящие в компании. Например, цепочка заказ покупателя->заказ поставщику->поступление товаров->реализация товаров->отгрузка со склада это бизнес-процесс, происходящий в организации, но его необязательно заворачивать в бизнес-процесс 1С или в какую-то другую программу.

                  >>Вы не читаете мои комментарии и начинает спорить сами с собой на тему домыслов из своей же головы.
                  Да понял я вашу мысль, что всё нужно оставлять типовым, потому что опасно что-то менять и дорого обновлять. У меня несколько иное мнение, которое уже озвучил. БП и ЗУП лучше оставлять типовыми. Управление торговлей я вообще не вижу смысла обновлять. Но спорить с ИМХОй не вижу смысла, в любом случае это скорее собственнику решать что ему важнее. На счет ЖКХ и медикаментов я даже не спорил, скорее уточнил про то, с чем сталкивался уже.

                  >> Предлагаю закрыть тему.
                  Ок.
                    0
                    > Я просто не понял к чему вы привели CasePress в контексте вопроса про то, чем можно заменить 1С.
                    Никто 1С не заменяет. Просто нет смысла ее дорабатывать под различные процессы обслуживания.

                    Примеры:
                    1. Организация занимающаяся обслуживанием компрессоров в УрФО, по 4м регионам РФ. У них БП на 1С, но вот им нужно сделать систему для учета объектов обслуживания (компрессора, насосы, промышленные кондиционеры ...), сделать учет заявок и совместную работу с клиентом. Зачем им дорабатывать 1С? Финансов в этом процессе почти нет, в основном идет учет сообщений и коммуникаций между сотрудниками и клиентом. Это легко настроить на базе CasePress. Дешевле и потом нет проблем с обновлением.
                    2. СМИ. Выпускает журнал и свой сайт, зарабатывают на рекламе. У них 1С БП 8. CRM на чем то другом. Решили переходить на CasePress, чтобы вести все взаимодействие с клиентом в одной системе. При этом бухгалтер остался на 1С, но получает отчет в в любое время о всех сделках которые подошли к этапу выставления счета, оформляет счет и отправляет, отмечает результат. Здесь данные между системами вносятся руками. Но это не проблема для клиента. Проблемой для него было то что раньше приходилось бегать туда сюда чтобы выставить счет. Сейчас бегать не нужно, т.к. нужная информация на любом рабочем месте доступна по одному щелчку.
                    3. Крупная контора оказывающая проф услуги. В 20 городах РФ. Под 1000 сотрудников. Процесс «Прием сотрудника». Понятно что он регистрируется в бухгалтерии, но вот стартует он службой персонала. Точнее есть пост «Ответственный за прием». Из за размеров организации, в разных офисах, этот пост занимают разные люди. Где то сам директор филиала, где то юрист, где то офис менеджер, а где то кадровый специалист, если филиал достаточно крупный.
                    Тут две проблемы:
                    1. попробуйте ка развернуть 1с на все эти филиалы — уже беда
                    2. нужно делать кучу настроек, с учетом того что разные типы сотрудников могут иметь этот доступ
                    3. есть определенные особенности и автоматические сценарии, которые нужно как то делать. В 1С — это опять же придется делать через изменение конфигурации со всеми вытекающими проблемами с дальнейшим обновлением.

                    В CasePress это делается проще. Добавляется модуль (который как мы знаем живет отдельно от ядра и не влияет на обновление), пишется сценарий, добавляется пост ответственный за прием сотрудников в каждом филиале и на этот пост назначаются люди. Теперь у них появляется право приема сотрудника. Они принимают сотрудников, затем маршрут запускается и данные о сотруднике попадают во все подразделения так или иначе задействованные в приеме. В том числе в бухгалтерию, которая забивает данные в 1С для правильного оформления и регистрации в финансовой системе.

                    И обратите внимание — процедура очень сложная и запутанная. Ставить каждому сотруднику 1С в этом случае довольно дорого. Еще дороже их потом обучать. И это так или иначе вызывает затраты на изменение 1С — лови потом проблемы с обновлением.

                    А тут максимально простая система, с привычным интерфейсом, работающая с любого устройства, в т.ч. с мобильного телефона, которая легко ставится на любом рабочем месте в любом филиале, потому что является облаком. Она бесплатна.
                    И ее можно как угодно модифицировать без боязни за обновления, потому что каждый ее модуль не зависим от ядра. Ядро обновляется, модули продолжают работать.

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