Предисловие
Речь в данной статье пойдет об информационных системах, используемых в торговых организациях. Эти базы данных обладают своими особенностями, к примеру, сильная зависимость сотрудников от информации, содержащейся в информационной системе. Другими словами, нет доступа к базе, нет работы, не выписываются документы, не отпускается со склада товар, остановлен анализ работы организации и еще много других неприятностей. Сорванные сделки, возмущение клиентов, потеря прибыли – это небольшой перечень проблем вызванных недоступностью информационной системы торгового предприятия.
Офисные и складские работники полностью полагаются на информацию, содержащеюся в базе данных, поэтому необходимо поддерживать точность содержащихся данных.
Современная российская торговля представляет собой бесконечный поиск и совершенствование услуг предоставляемых клиентам. Постоянное увеличение и совершенствование ассортимента и все для того чтоб привлечь как можно больше покупателей и увеличить оборот товаров и денег.
Государство тоже не дает покоя, постоянно выставляя все новые и новые требования и изменяя правила торговли.
В таких условиях информационная система пребывает в постоянных изменениях. В жесткой конкуренции приходится снижать торговую наценку и сокращать издержки, искать ту грань лезвия ножа, при которой остаются финансовые средства на развитие и в тоже время остается конкурентоспособная цена товаров.
Информационная система является тонким инструментом, который отделяет богатство от разорения. Наиболее успешной в наше время является та торговая организация, у которой более совершенная система используемая сотрудниками для процессов торговли и анализа.
Надеюсь, мне удалось передать всю ту меру ответственности, которая ложится тяжким грузом на разработчиков системы. После осознания всех проблем, становится понятно, почему разработчики внутри торговой организации, так неохотно соглашаются произвести изменения в информационной системе, но как мы уже выяснили, постоянные изменения просто необходимы для победы в конкурентной борьбе.
Введение
Для успешного выполнения проектов в области программного обеспечения необходима работа нескольких участников, выполняющих определенные роли.
Необходимо отказаться от стереотипа, что все изменения делает программист, если возложить все заботы о функционировании и изменении информационной системы на разработчика, значит создать массу проблем при работе с информацией.
Программист - человек творческий, и ему, как правило, нет дела до взаимодействия с клиентами, торговыми наценками, конкурентами и еще бесконечный список до чего ему нет дела. Но есть самое главное, что он умеет делать лучше всех – создавать алгоритмы и программы. Вот именно этим его и нужно озадачить и возложить остальные роли на других людей привлеченных к процессу создания программного обеспечения.
Любой проект в области программного обеспечения делится на два больших этапа: разработка и эксплуатация.
Некоторые роли больше учувствуют в разработке и создании проекта, некоторые более востребованы при эксплуатации.
Этап разработки трудоемкий и занимает, в идеале, несравнимо меньше времени по сравнению с этапом эксплуатации программного продукта.
На этапе разработки формируется проект, привлекаются высоко квалифицированные специалисты для непосредственного участия в написании кода, подготовки аппаратного и другого программного обеспечения для функционирования проекта.
Совершенно неважен уровень сложности программного обеспечения, создаваемый для решения задач торговых организаций, успех работы в этом направлении зависит от участников и их добросовестного исполнения заданных ролей.
Роли участников проекта разработки программного обеспечения
На любом этапе, для программного продукта предусматривается не менее шести ролей. Специфика определенных проектов может потребовать больше ролей, но для целей торговли как раз шести хватит.
Количество исполнителей определенных ролей в проекте может быть более одного человека, тогда обязательно для каждой роли должен быть старший, который несет ответственность за функциональное участие в проекте.
Роли, определенные для разработки и функционирования программного продукта:
- Менеджер продукта.
- Менеджер проекта.
- Разработчик (программист).
- Системный администратор, специалист в БД.
- Тестировщик.
- Служба поддержки пользователей.
Менеджер продукта – инициатор проекта. В задачи и обязанности этой роли входит определение потребительских свойств проекта и функции, выполняемые программным продуктом при эксплуатации. Также специалист, выполняющий данную роль должен обеспечить ресурсами создание и эксплуатацию проекта.
Менеджер проекта – распорядитель ресурсов. В обязанности этой роли входит распределение ресурсов, выделенных на проектирование и эксплуатацию программного продукта. За конечный результат отвечает персонально именно этот человек, в связи с этим специалист, выполняющий эту роль, утверждает все решения, принимаемые при работе с программным продуктом. Таким образом, последнее слово при принятии решений остается за данной ролью и никакой демократии не предполагается. Кто отвечает за результат, тот и принимает все решения по распределению ресурсов.
Разработчик - создатель программ. В обязанности этой роли входит предложение средств разработки программного продукта, создание программного кода с помощью утвержденных средств разработки.
Системный администратор – подготавливает аппаратное и программное обеспечение для функционирования созданного программного продукта. Обеспечивает резервное копирование данных, распределение прав пользователей, создание пользователей.
Тестировщик – проверяет работоспособность кода и проверяет соответствие работы системы заданному проекту. Подготавливает отчеты о готовности программного продукта к эксплуатации.
Служба поддержки – консультирует пользователей при возникающих у них проблемах. Создает инструкции по использованию программного продукта. Проводит обучение пользователей.
Пример взаимодействия участников при создании проекта
Для лучшего понимания обратимся к примерам из жизни. Сначала рассмотрим, как делать не надо, ибо будет потрачено время и усилия, но результата в лучшем случае не будет, а чаще всего становится только хуже.
Представим себе офис программиста, в который без стука зашла миловидная девушка и с нотками флирта начала беседу:
- Привет, Виталий.
- Привет, Маша, - произнес программист, неохотно отрываясь от своих дел. Ему через 2 часа нужно отдать директору отчет, а до его готовности еще далеко.
- У меня есть идея. Ты можешь сделать, чтобы я могла печатать все документы не из 1С, а из Word’а.
- Конечно, без проблем, набирай документы вручную и печатай, сколько захочешь, - съязвил программист, которому явно не хватит времени на выполнение более важного задания, а приходится болтать, хоть и с миловидной, но весьма надоедливой дамой.
- Ты меня не так понял, - не унималась Маша. – Мне это облегчит работу …
- Мне сейчас не до этого, есть более важные дела, - перебил ее Виталий. – Согласуй это с директором, потом посмотрим, как это сделать.
Девушка почти в слезах выбежала из офиса, громко хлопнув дверью.
Программист вернулся к своей работе, погрузившись в мир цифр и алгоритмов, но прошло немало времени, прежде чем ему удалось найти нить, упущенную при посещении Маши.
При этом возможны два варианта событий, удачный и сложный.
При удачном развитии событий Маша затаит обиду и припомнит программисту его поведение, но идею воплощать в жизнь не будет.
При сложном развитии событий, Маша заручится поддержкой директора, и программист получит распоряжение озадачиться проблемами Маши и сделать, то, что она хочет.
В офисе программиста появляется торжествующая Маша и с порога выпаливает:
- И все-таки ты сделаешь, что я тебе скажу.
Мрачный программист осмотрел посетителя. Только что рухнул сервер, зам директора прислал задание, директор срочно хочет увидеть цифры прибыли за прошлый год, главный бухгалтер требует провести документы, чтоб она могла сдать годовой отчет и еще невероятное количество дел, которые не сделать никогда.
- Видишь список? – спросил Машу программист. – В нем двенадцать записей, я тебя могу записать тринадцатой, писать?
Машу передернуло, видимо суеверие взяло верх. Программист даже не подумал, что Маша прониклась количеством забот Виталика, просто посетителя не стало в кабинете.
Данный пример красноречиво иллюстрирует распространенное, но не эффективное взаимодействие сотрудников компании.
Главная ошибка Маши в том, что она совершенно не учитывает интересы всей компании, а только свои личные. Не понимает, что есть масса работы, без которой высокооплачиваемого специалиста руководство организации не оставит. И главное, полное отсутствие продуманного проекта по разработке и эксплуатации программы, без которого опытный программист не станет приступать к исполнению проекта изменения информационной системы.
Рассмотрим пример удачного взаимодействия при разработке программного обеспечения.
В кабинете заместителя директора появился руководитель одного из отделов компании Владимир.
- Михаил Семенович, здравствуйте, - уверенным голосом сказал посетитель.
- Здравствуй, Владимир, проходи, располагайся, - ответил ему хозяин кабинета. – С чем пришел?
- У меня есть идея, как улучшить работу сотрудников компании.
Михаил Семенович с интересом смотрит на инициативного сотрудника, взглядом предлагая продолжать.
- Нужно, чтобы сотрудники компании в информационной системе получали задания и выполняли их, тогда станет работать легче и контролировать результат проще.
Владимир завозился, доставая бумаги из папки.
- Я тут техническое задание накидал. Прикинул, что наш программист сможет все это реализовать.
- Молодец, Владимир, - похвалил его Михаил Семенович. – Давай прикинем, кто у нас какие роли исполнять будет.
- Я уже все расписал. Менеджер продукта я, менеджер проекта Вы.
- Подожди, не так быстро, - выставив руки вперед, остановил Владимира без пяти минут менеджер проекта. – Мне нужно все оценить, оставляй бумаги и заходи ко мне завтра.
Таким образом должен начинаться проект. Вначале Менеджеры продукта и проекта договариваются между собой, Менеджер проекта внимательно знакомится с техническим заданием и оценивает предложенные и необходимые для выполнения проекта ресурсы и соглашается на эту роль только тогда, когда уверен в успехе дела, ведь за результат отвечать ему.
О целесообразности проекта заботится Менеджер продукта, защищает свою точку зрения, когда обосновывает необходимые ресурсы для этого проекта. Удобно, когда есть достаточно своих ресурсов, чтоб не нужно было никому ничего объяснять, а только найти Менеджера проекта, который согласится на таких условиях и с помощью доступных ресурсов реализовать задуманное.
На следующий день в кабинете заместителя директора.
- Владимир, заходи, - сказал хозяин кабинета. – Я рассмотрел твое предложение и принимаю его.
- Спасибо, Михаил Семенович, - сказал обрадованный Владимир.
- Итак, менеджеров мы выбрали. Разработчиком будет Виталий, системным администратором серверов назначим его же.
- Тестирование я сам проведу, службой поддержки будет Маша.
- Отлично, кто нам сделает проект системы?
- Проект будем делать совместно я и Виталий, - сказал воодушевленный Менеджер продукта. – Сроки реализации будут указаны в проекте, с учетом текущих задач стоящих перед Виталиком.
- Хорошо, мне иногда кажется, что Виталию нужен помощник, он тогда больше времени сможет посвятить задачам развития нашей информационной системы.
- Я согласен, Михаил Семенович, - сказал Владимир, выходя из кабинета.
Возможности совмещения ролей
Проекты бывают разной сложности и иногда целесообразно не привлекать 6 человек для исполнения всех ролей проекта, а совместить исполнение обязанностей одному человеку, как в приведенном примере.
Менеджер продукта может также эффективно исполнить роль тестировщика, разработчик нередко совмещает роль системного администратора.
Это примеры удачного совмещения. Так же хорошо совмещаются роли тестировщика и службы поддержки.
Количество сотрудников в проекте может сокращаться до трех человек. Главное правильно совместить роли не понизив эффективность работы коллектива.
Классический пример, когда совмещаются роли: Менеджер продукта-Тестировщик, Менеджер проекта-Разработчик, Системный администратор-Служба поддержки.
Роли Менеджера продукта и Менеджера проекта совмещать нельзя ни в коем случае! Из взаимодействия этих ролей как раз и рождается движение к выполнению проекта. Как в диалектике единство и борьба противоположностей.
При совмещении ролей Менеджеров появляется соблазн сократить функциональность проекта, а это иногда полностью уничтожает смысл реализации.
Но самые несовместимые роли – это Разработчик-Тестировщик. Программист может провести только предварительное тестирование, но этого совершенно недостаточно для сдачи программного продукта в эксплуатацию.
Из всего этого следуют выводы:
- Минимальное количество людей, задействованных в создании и эксплуатации программного продукта трое, но они выполняют шесть ролей.
- Совмещать роли нужно продумано, не более двух на человека.
- Успех проекта заключается в простом девизе: Все взяли на себя обязательства и выполнили их.
