Карьерный гид специалиста DIRECTUM
В этой статье я не столько делюсь своими наблюдениями, сколько призываю сообщество к дискуссии и предлагаю участникам поделиться своим опытом в этом вопросе.
Статью объявляю живой и обновляемой по мере поступления новой информации.
Критикуйте, комментируйте, делитесь своим опытом.
Какие специалисты по DIRECTUM существуют?
В моей упрощённой картине мира существуют четыре основных вида специалиста.
1. Технарь
Специалист, который хорошо разбирается в технических аспектах системы: знает, как развернуть систему; где крутится её база данных; как импортировать разработку; как завести нового пользователя; создать новый справочник, типовой маршрут и может разобраться в вопросе «почему эта кнопка не работает?».
К технарям я отношу администратора и разработчика.
Задача администратора – поддерживать работоспособность текущей версии системы: заводить пользователей, делать бэкапы (и разворачивать их при необходимости), разворачивать новые компоненты системы (веб-доступ, сервер репликации, служба преобразования), мониторить работоспособность системы, оптимизировать производительность системы, следить за чистотой базы системы, настраивать терминальный сервер для доступа пользователей DIRECTUM (или как минимум знать, какие мощности нужны для этого сервера с учётом количества одновременно работающих пользователей) и т.д.
Задача разработчика – изменять текущую версию системы, т.е. модифицировать её, создавать новые объекты, изменять существующие, интегрировать систему DIRECTUM с другими системами (например, 1С), подстраивать систему DIRECTUM под нужды пользователя (проще говоря – добавлять «кнопочки») и т.д.
Часто обе роли совмещаются в одной с тем или иным перекосом – где-то нужен больше администратор, который отвечает на вопросы пользователей и немножко модифицирует систему, а где-то разработчик, который заводит новых пользователей и разворачивает веб-доступ. Всё зависит от масштабов компании и её потребностей.
Технари если и общаются с реальными людьми (пользователями), то чаще всего по вопросам ошибок. В большей степени они общаются с компьютером и проектом, который придумал аналитик (смотри ниже).
Ценность технаря в его глубоких знаниях конкретной системы (конкретного инструмента).
Инструменты технаря: Microsoft Windows Server, Microsoft SQL Server, различные скрипты и утилиты, дистрибутивы, служба поддержки DIRECTUM, утилиты администратора DIRECTUM, утилиты разработчика DIRECTUM, лог-файлы, языки программирования (SQL, ISBL, VBS).
Командировки бывают редко, в основном работа идёт в офисе (если вы технарь партнёра или вендора - об этом ниже).
2. Аналитик
Для меня аналитик (или – дизайнер, инженер, проектировщик) – это специалист, который проектирует будущую систему или какую-то её часть. Иногда этих специалистов называют «бизнес-аналитик».
Задача аналитика – спроектировать будущее решение.
Аналитик общается с будущим потребителем системы (пользователем, заказчиком), узнаёт что тот хочет (как заказчик работает сейчас без системы) и после собранной информации описывает то, как заказчик будет работать в системе, как будут автоматизированы его процессы.
Активно взаимодействует с заказчиком на этапе проектирования и согласования проекта, а после того, как разработчик реализует проект в системе, то тестирует эту разработку, пишет инструкции для будущих пользователей и обучает их.
Аналитик в виду своей деятельности погружается в предметную область заказчика, в процессы, которые проходят внутри заказчика, узнаёт их. Например, как согласуется такой документ, как договор, зачем нужен делопроизводитель и как ставятся поручения, что за документ «доверенность» и как она выдаётся и т.д.
Ценность аналитика в его знаниях процессов заказчика, в умении узнавать эти процессы и умении их оптимизировать и описывать (в умении «копать» глубоко).
Инструменты аналитика: сотрудники заказчика (пользователи), блокнот или диктофон (для записей слов заказчика), Microsoft Word (для оформления проекта), Visio (для рисования схем процессов в IDEF), технологии сбора данных.
Командировки бывают часто в начале проекта и по его завершению.
3. Руководитель проекта (РП)
Управленец, человек, который планирует предстоящие работы, оценивает их трудоёмкость, длительность, контролирует команду и делает так, чтобы работа была выполнена в срок, затраты на выполнение задачи были в пределах нормы и сделано именно то, что было задумано.
Задача РП – сделать так, чтобы задача была решена вовремя и с оптимальными затратами.
РП знает свою команду – их квалификацию и особенности (одного надо постоянно «пинать», другой наоборот от этого бесится, с третьим нужно периодически говорить по душам).
РП представляет и планирует будущую работу – на входе он получает задачу («Хотим автоматизировать договоры, у нас 100 пользователей»), на выходе он сначала даёт спецификацию (документ, в котором расписано какие этапы есть у предстоящих работ, сколько часов уйдёт на каждый этап и сколько это будет стоить для заказчика с учётом часовой ставки), дальше он планирует эти работы с учётом рабочего календаря, определяется с командой проекта, учитывает их загрузку, отпуска, закладывает время на больничные и фазы Луны.
Решает вопросы типа «мы хотели вот так, а вы нам сделали вот так – теперь переделывайте бесплатно» или «я не хочу работать в вашей системе» или «то, что вы сделали, нам не подходит».
Контролирует срок, бюджет. Мотивирует команду как заказчика, так и исполнителя. Точно знает какие работы за какими идут. Знает как где-то ускориться, где-то сделать подешевле, кого нужно слушать, а кого нет.
Ценность РП в его силе воли и умении доводить дело до конца (даже в случае проблем и сложностей).
РП иногда привлекают на предпродажные работы (pre-sale) – встречи с потенциальными клиентами, на которых обсуждаются детали системы или конкретного решения.
Инструменты РП: спецификация, Microsoft Project, календарь, телефон, сотрудники (технари и аналитики), технологии управления проектами (PMBOK), технологии управления людьми.
Командировки бывают часто.
4. Продавец
Приносит проекты для компании, т.е. деньги. Ищет новых заказчиков, раскручивает текущих.
Задача продавца – добиться встречи с потенциальным клиентом и на встрече продать клиенту в первую очередь себя, а уже во вторую – систему и компанию.
Знает систему постольку-поскольку, т.к. чаще всего для него не так важно что продавать – DIRECTUM, SAP или 1С.
В душе бизнесмен, волк-одиночка. Сидит на проценте от заключенных сделок.
Выбивает деньги с заказчика, если тот отказывается платить.
Для понимания сути продавцов рекомендую: http://www.youtube.com/watch?v=VSwK3ju3qaY
А также вот это: http://www.youtube.com/results?search_query=сергей+филиппов
Инструменты продавца: костюм, ноутбук с демонстрационной версией DIRECTUM, PowerPoint (с презентацией), визитки, телефон, обаяние, уверенность, наглость, прайсы, договоры, CRM, госзакупки.ру, технология продаж и обработки возражений.
Продавец постоянно в разъездах.
Кого не перечислил, но встречал среди специалистов DIRECTUM: специалисты ТМЦ (обзванивают потенциальных клиентов, прощупывают интерес, работают в связке с продавцом), преподаватель (специализируется на обучении системе), администратор проекта (помощник РП на крупных проектах), инженер поддержки (решает обращения пользователей), консультант (начинающий аналитик).
Где обитают эти специалисты?
Опять же в моей упрощённой картине мира выделяются три типа компаний, где работают эти специалисты.
1. Вендор
Он же – разработчик программного обеспечения. Компания, которая создала систему DIRECTUM или любую другую.
DIRECTUM для вендора – это его детище, его всё.
У вендора встречаются все виды специалистов (хотя некоторые вендоры, например, компания 1С, внедрением системы не занимается).
В случае с DIRECTUM, штаб-квартира находится в Ижевске, но также есть представительство в Москве. Насколько мне известно, сейчас вендор активно привлекает кандидатов не только в своём регионе (УР), но и за его пределами, а также в Москве и области.
Сайт вендора: http://www.directum.ru/
2. Партнёр
Компания, которая решила зарабатывать на услугах, оказываемых по системе DIRECTUM: продавать и внедрять систему у новых заказчиков, выполнять доработки (сопровождать) системы у текущих заказчиков.
Параллельно эта компания может зарабатывать на услугах по другим системам (1С, SAP) и вообще других услугах.
Работа у партнёра полна разных задач, новых проектов, новых клиентов, партнёру зачастую требуются универсалы.
У партнёра можно получить хороший опыт и вырасти до опытного специалиста.
У партнёра встречаются все виды специалистов.
Список партнёров: http://www.directum.ru/partners
3. Клиент
Компания, которая использует в своей работе DIRECTUM. Это может быть Банк, Министерство Сельского Хозяйства, Макдональдс или поставщик алкогольной продукции (в общем, кто угодно).
Система для них – это один из инструментов, который помогает им вести бизнес (упорядочивает его, делает бизнес прозрачнее, управляемее).
Часто у клиента есть свой ИТ отдел, в котором один-два-три (в зависимости от размеров) специалиста занимаются DIRECTUM.
Ежедневно они сопровождают и развивают одну и ту же систему и общаются с одними и теми же людьми (классно, для тех, кто предпочитает стабильность).
У клиента не бывает продавцов, а РП чаще всего выделяется только на время внедрения системы. Больше всего у клиента востребованы технари, дальше идут аналитики и уже после – РП.
Список компаний, у которых установлен DIRECTUM: http://www.directum.ru/clients
Путь воина
Варианты развития зависят от особенностей и потребностей каждого конкретного индивидуума. Я не буду давать подробного ответа о том, куда и как развиваться - намечу лишь варианты.
И главное помнить – это всего лишь некоторые варианты, а жизнь сложнее и развитие может быть разным.
1. Орк (технарь)
Можно оттачивать свои знания инструмента, углубляться в него и стать экспертом-технарём по DIRECTUM, который знает, как развернуть систему в кластере или который разрабатывает новый модуль за несколько дней.
Такие специалисты ценятся и востребованы, их труд хорошо оплачивается, они легко находят новую работу, т.к. привязаны больше к инструменту, нежели к конкретной компании.
Путь может быть таким:
Технарь-стажёр (отвечает на вопросы пользователей, решает ошибки, изучает систему) -> Администратор-разработчик (делает доработки, участвует в проектах, у партнёра или клиента) -> Администратор 80 уровня ИЛИ Разработчик 80 уровня ИЛИ Ведущий разработчик (не столько эксперт по разработке, сколько управленец).
В принципе, технарь может пойти и в аналитики и в продавцы и в РП (знание системы везде пригодится).
2. Друид (аналитик)
Сначала начинает консультантом (помогает аналитику, оформляет инструкции для пользователей, консультирует пользователей по реализованным процессам).
Потом становится аналитиком и уже сам полностью проектирует весь процесс (от сбора информации до оформления проекта).
Потом начинает специализироваться на каких-то конкретных процессах, например, «делопроизводство» или «согласование договоров в банках» (именно в банках) или на чём-нибудь таком.
А может становиться ведущим аналитиком и больше ударяется в управление другими аналитиками или вырастает до РП.
Аналитики больше привязаны к процессам, нежели к инструменту (системе).
Вакансии для аналитиков я встречал нечасто, но они есть.
3. Маг (РП)
РП чаще всего появляются из аналитиков.
Путь РП следующий: сначала берёт первый проект (важный момент); потом делает второй-третий проект (закрепляет полученный опыт); дальше пробует вести параллельно два проекта; потом ведёт один проект сам, а по другому проекту курирует другого РП; и в конце – управляет портфелем проектов (т.е. целой пачкой проектов).
РП востребован и высокооплачиваем, но чтобы уйти из одной компании в другую на должность РП, нужно удовлетворять требованиям типа «опыт управления проектами от 3-х лет» или «как минимум 3 успешно реализованных проекта» или «сертификат по PMBOK».
4. Некромант (Продавец)
Развитие продавца идёт в увеличении суммы закрываемых сделок и, как вариант, в перспективе в открытии собственного бизнеса, т.к. именно умение продавать и находить клиентов – основа бизнеса.
На мой взгляд, продавец - один из самых востребованных специалистов на рынке (их постоянно не хватает).
Получают много, если умеют продавать.
Востребованность и з\п
Рекомендую подписаться и периодически читать, отслеживать, понимать кто, кому и за какие деньги нужен: http://www.hh.ru/search/vacancy?text=directum+OR+директум&area=1
Где почерпнуть знания?
По DIRECTUM (сообщество специалистов по системе): http://club.directum.ru/
По документообороту в целом (много теории, сам я этот портал не читаю, т.к. предпочитаю практику): http://ecm-journal.ru/
Вкусно-вкусно-вкусно!
Поехали.
Не совсем верно. Бедные-бедные аналитики, иногда мне кажется, что это едва ли не одна из самых уязвимых в плане определения профессий - никто толком не уверен, чем они занимаются и как называются =)
Бизнес-аналитик - это человек, который исследует бизнес-процессы вверенного ему участка работы (отдела, подразделения, предприятия), собирает требования к возможной автоматизации этих процессов. Работа бизнес-аналитика в идеале на систему вообще не заточена. А вот проекция этих бизнес-процессов и требований на некоторую систему и проектирование такой системы - это уже задача системного аналитика. Более того, если мы говорим об аналитиках партнёров, не ограничивающихся внедрением DIRECTUM - тут ещё и выбор системы может осуществляться.
мвахахахаха...
пацталом... :)))
Иван, спасибо за материал! Думаю для многих действительно актуальный срез.
Первая публикация на клабе с тегом "карьера", новые горизонты для направления HR?
По собственному опыту скажу, что знание системы после 1.5 лет работы в службе поддержки DIRECTUM очень пригодились в работе администратором проекта внедрения. Да и собственно сам опыт работы поддержки (аналитическая часть, знание, где, как и что найти и прочие особенности) помогают и сейчас. Могу сказать, что необязательно расти в одной плоскости
Следующий момент:
Лично мне таких продавцов хочется убиватьубиватьубивать. Это если честно.
Потому что такие продажи заканчиваются очень тяжёлыми проектами. Потому что такие продавцы обещают клиенту функционал, который либо сложно, долго и костыльно реализуем, либо нереализуем в принципе из-за ограничений платформы. Потому что если едешь с такими продавцами на пресейл, во время презентации волосы шевелятся везде, где не зафиксированы укладочными средствами, ибо сначала пытаешься переварить озвученное, а потом лихорадочно думаешь - как поправить непоправимое, да попутно ещё корпоративную этику соблюсти.
В моём понимании продавец должен не только знать продаваемую систему, но и, как это ни странно, должен быть средним предметником, т.к. на показах среди ЛПР всё чаще присутствует не только топ-бизнес, но и владельцы процессов, задающие вполне конкретные вопросы, на которые не помешало бы знать точные ответы.
Полностью согласен с Валентиной.
Не соглашусь с тем, что продавец знает систему "постольку-поскольку". Он конечно может быть таким, но хороший/успешный продавец знает систему (а особенно ее применение под заказчика) лучше разработчика, и кроме того обладает серьезными знаниями технологии внедрения.
Такие требования предъявляет к продавцам компания DIRECTUM. Опытные продавцы компании в том числе могут на практике показать возможности инструмента разработки.
Аналогичный подход к развитию продавцов мы ждем и от наших партнеров.
Читается материал легко, на одном дыхании) Еще бы увидеть материал - отзыв о работе специалиста, который совмещает и РП, и Технаря, и Аналитика. Сам себе пишет ТЗ, сам реализует, сам ставит сроки, сам обговаривает их с заказчиком. Такие универсалы появляются, когда клиент решает внедрять систему собственными силами). Как у них проходит рабочий день?))
Иногда работа технаря больше работу некроманта напоминает
Ах да, об универсалах.
Очень двоякая ситуация получается.
Работодатель чаще всего считает универсала специалистом, которому можно платить меньше, чем двум/трём неуниверсалам. Действительно - я не видела ни одной компании, где ставка универсала рассчитывалась бы, как сумма ставок специальностей им совмещаемых.
При этом нельзя не понимать, что хороший - действительно хороший - универсал стоит дорого. В том числе и потому, что выращивается долго. Хорошим целевым спецом можно стать за год-полтора. Хорошим универсалом - нет.
Ориентированность партнёров и клиентов на универсалов понятна - масштабы позволяют. Вендор же больше ориентирован на целевых спецов (сразу оговорюсь, что это не означает невозможности существования универсалов у вендора в принципе). Чем это чревато?
В вендоре вырастает целевой специалист - серьёзный, грамотный, опытный, хорошо оплачиваемый. И, достигнув потолка, или по иным причинам решает сменить работу. На рынке труда такой специалист оказывается в крайне невыгодных условиях. На универсала он не тянет, т.к. не владеет или недостаточно владеет одной или несколькими составляющими. Условно говоря - его если и возьмут, то лишь универсалом-джуном, что автоматом означает существенную потерю в уровне дохода (я говорю сейчас о переходах внутри одного города).
Возможна и другая ситуация, когда даже ставка "нормального" универсала изначально ниже того, что на данный момент имеет целевой специалист.
Я сознательно не рассматриваю сейчас нематериальную сторону - наработка опыта, смена профиля, расширение горизонтов, это всё понятно.
Продажи driven development
Валентина, исхожу из того что мы все-таки говорим про ИТ-область, область ИТ-проектов, причем DIRECTUM. Поэтому не могу согласиться с тем, что:
Из этого утверждения может сложиться мнение, что бизнес-аналитик это такой специалист по "вакуумным" процессам. Т.е. он хорошо знает разные способы оптимизации процессов, и его совершенно не интересуют какие-то там ограничения конкретно взятой системы автоматизации. Боюсь, что если такого бизнес-аналитика допустить к ИТ-проекту, это приведет к (заменить "продавец" на "бизнес-аналитик"):
На проектах DIRECTUM именно бизнес-аналитик обеспечивает проекцию бизнес-процессов в систему DIRECTUM. Его задача обеспечить эффективное использование существующего функционала системы для покрытия требований заказчика.
А системный аналитик крайне редко выходит на заказчиков, у нас они занимаются развитием платформы.
Вопрос в большей степени терминологический, но если сразу не ограничить область, то мы можем уйти в сторону бизнес-аналитиков, подготавливающих компанию к продаже или IPO и прочих задач из сугубо бизнесовой сферы.
Денис, именно из-за этих "внутренних особенностей DIRECTUM", аналитики, выходящие за пределы компании, сильно удивляются, что привычное им наименование абсолютно не совпадает с рынком труда, требующего от него совсем иные задачи. Наши аналитики - микс из BA, SA и RA, своеобразные "универсалы от аналитики", сталкивающиеся со всеми теми проблемами, о которых я написала в комменте про универсалов.
Валя, ты про рынок труда в какой сфере говоришь?
Действительно ситуация с бизнес-аналитиками сейчас такая, что в каждой сфере имеется в виду что-то свое. Я склонен считать, что в области ИТ-автоматизации бизнес-аналитик обязан хорошо знать возможности системы, которую он внедряет. И это совсем не "внутренние особенности DIRECTUM".
В сфере IT. Я абсолютно согласна, что в идеале все аналитики, продавцы, разработчики и РП должны знать системы, которые внедряют. Но вне компаний, ориентированных на жёсткую привязку к системе (или нескольким), БА может вообще ничего не внедрять =)
Жаль нельзя лайкать комментарии
. В целом, поддерживаю Дениса.
Ну сфера ИТ сама по себе широкая. Да. Может и не внедрять, а в разработке участвовать, если ты об этом. Только тогда он должен ориентироваться в тех ИТ-технологиях, в области которых ведется разработка. Ну или просто будет вынужден с низов расти, осваивать эти технологии на новом месте.
Еще интересно услышать мнение сообщества по поводу того, как вы начинали свой карьерный путь, где находитесь сейчас и в чём видите своё развитие: где учились (на гумманитарной или технической специальности), как попали в компанию и на эту должность, что сейчас изучаете, какие вопросы\темы вас интересуют.
Начало моего карьерного пути описано тут: http://npo-comp.blogspot.ru/2011/01/blog-post_26.html
Главное, что бизнес-аналитики со знанием возожностей системы более полезны заказчику.
Одна знакомая компания очень ругала "Янгов" http://www.ey.com/RU/ru
за то, что они как раз делали свой аудит, целью которого было внедрение системы, совершенно без привязки к имеющейся у предприятия системе. Так как теперь нужно делать еще раз бизнес-анализ. Не каждая компания готова платить дважды...
Алексей, я пост-то до сих пор отлайкать не могу
Денис, об этом и речь =)
Иван, а ты не планируешь участвовать в дискуссии?
Елена, здесь уже как раз показатель непрофессионализма.
Если цель аудита - внедрение системы, его в принципе нельзя проводить без привязки к системе.
Ну объяснение-то у Янгов вроде бы красивое - они делают аудит для автоматизации, но они выше того как это будет реализовано. Они делают "аудит" в "чистом" виде для "высоких" бизнес-целей. Без доказательств профессионализма вряд ли они бы смогли раскрутить на свои услуги. Проблема-то она уровень ИТ-шников вываливается в виде приказа "Вот вам результаты бизнес-анализа - сделайте нам хорошо". И теперь хочешь-не-хочешь итшнику придется стать бизнес-аналитиком.
Я считаю, что любой из специалистов DIRECTUM от технаря до продавца должен разбираться в инструменте, на котором он специализируется. Другой вопрос - насколько глубоко.
Судя по дискуссии, бизнес-аналитик разбирается в системе на уровне, достаточном для проектирования, системный-аналитик обладает более глубокими знаниями системы и на крупных проектах (в крупных компаниях) является прослойкой между бизнес-аналитиком и технарём. Почему бы и нет.
Что касается продавца, то лично мне тоже хотелось бы, чтобы они разбирались в системе настолько хорошо, что могли бы даже маршрутик наваять, но насколько это реально - я судить не могу. Как минимум знать систему на уровне пользователя и, в идеале, начальном уровне администратора (развернуть, например) - знать полезно.
Ему как раз придётся стать системным аналитиком (в общей, не DIRECTUM-терминологии) =) "натянуть" бизнес-требования на систему.
У меня сладывается такая картинка расстановки производственной команды (продавца выносим за скобки):
- на маленьких проектах (а лучше назвать их задачах): технарь-аналитик-РП (универсал, джазмен)
- на мало-средних проектах: технарь +аналитик-РП
- на средне-крупных проектах: технарь +аналитик +РП
- на крупных проектах: администратор +разработчик +аналитик +РП
- на мега проектах: инженер поддержки +администратор +разработчик +системный аналитик +бизнес-аналитик +администратор проекта +РП
И все эти ребята в той или иной степени знают систему DIRECTUM.
они как раз делали свой аудит, целью которого было внедрение системы, совершенно без привязки к имеющейся у предприятия системе
Задача абсалютного обльшинства компаний-внедренцев - продать как можно больше (в первую очередь лицензий). Исходя из этой задачи бизнес-аналитик партнера вендора "натягивает" существующие процессы заказчика на систему. А изменение процесоов часто бывает связяно именно с ограничениями системы. И инетересно получается, когда сэйл совмстено в аналитиком продал набор компонентов (инструментов), а в ходе проекта команде уже приходится опять натягивать, может и не нужные заказчику, вещи (компоненты). - - возмоности системы станадртные, но вопрос ЗАЧЕМ? А вот именно на этот вопросы "ЗАЧЕМ?" и деложен отвечать настоящий БИЗНЕС-аналитик. Вопрос "как" уже вторичен, и это задача уже группы внедрения системы. БИЗНЕС-аналитик - человек заказчика. Его инструмент - секундомер(!) и excel, ну и интернет конечно же. РП - это не внедренец, РП - в первую очередь, менеджер! Он, как и аналитик, также умеет "читать" организацию как СИСТЕМУ. Все её элементы, связи, больные места ... Да, РП тоже аналитик, но уже по предметной области уровня управления.И все эти ребята в той или иной степени знают систему DIRECTUM.
Не согласен. системы должны знать внедренцы. Внедрение БИЗНЕС приложения - это проект Бизнесовый. При выборе системы хороший аналитик может ограничиться открытой информацией в инетренете, не зная досконально конкретно какой-то одной. Знать систему - хорошо!, Но понимать бизнес-задачи, уметь выбить на совещании с внедренцами инструменты только те, которые нужны - вот навыки аналитиков и РП, как специалистов по работе с людьми.
У нас из компании ушел второй разработчик (я типа как первый по хронологии) на работу с ASP.NET и мы теперь ищем нового. Дословная цитата из письма нашего кадровика: "Общалась с опытными в плане разработки модулей кандидатами, но они хотят уже уйти от Директума."
Проблема развития в плане работы с Директумом, на мой взгляд, именно в том, что очень ограничен набор сценариев, в которых можно использовать DIRECTUM. После десятого-пятнадцатого по счету внедрения договорного процесса уже банально устаешь делать одно и то же. Отличия минимальны, профессионального развития уже никакого. Меня в свое время спасло то, что после прихода на нынешнее место работы я получил функции бизнес-аналитика с вкраплением функций РП.
Новость о выпуске СЭД DIRECTUM датируется концом 2002. Интересно, есть кто-то, кто занимается разработкой в Директуме или его внедрением 9-10 лет без смены поля деятельности?
Я вижу рассхождение ожиданий работодателя и работника.
Работодателя в данной дискуссии представляют Денис Садыков и Андрей Старков. Они хотят, чтобы работники знали систему DIRECTUM и хорошо в ней разбирались. Резонно.
Работников олицетворяют Дмитрий Михалин и Валентина Писанова, которые говорят, что не обязательно быть привязанным к инструменту, главнее к технологии и общим знаниям. Понимаю их, т.к. отвязка от продукта делает их более универсальным товаром на рынке труда. Опятьже резонно.
Моё мнение такое: и рыбку съесть и ... не получится. Если работник хочет развиваться внутри той компании или сообщества продукта, к которому он сейчас принадлежит, то придётся погрузиться в специфику этого продукта невзирая на риск того, что ты станешь не универсалом.
Поправьте меня, если я ошибаюсь.
Андрей Куров поднял интересный вопрос - что делать, если ты уже "всё знаешь" и стало "скучно".
Кто как борется с тем, что мы назовём "скука" и возникает ли она у вас?
Вопрос в первую очередь к разработчикам (почему-то именно у них, как мне кажется, этот вопрос часто встаёт).
Ой-ой-ой!!! Нет!!!
Если бы я так считала - писала бы я свой стон души о продавцах, не знающих систему?
Валентина, прошу прощения, получается тебя я ошибочно втянул в это обобщение.
Небольшой комментарий по поводу "разработчику стало скучно, что делать".
Возможно, ответ кроется в статистике по проектам наших партнеров. Увы, но большинство - это реализация задач делопроизводства. Чем занимаются продавцы в таких компаниях? Набив руку на совершении простых продаж, обеспечив постоянный приток денег, но не замахиваясь на что-то большее, фактически "убивают" карьеру разработчиков в своей компании...
Изменить такую ситуацию в компании может только руководитель, иначе разработчики будут увольняться.
Как пример такой ситуации: отдыхаю душой тем что, создаю (если это возможно) отчёты на MS Reporting Services, а тут уж SQL позволяет и напрячь мозг, и получить впрыск в мозг эндорфинов от изящности конструкций и идеально решённой задачи. Вообще SQL сам по себе даёт возможности бесконечного самосовершенствования. Тем и спасаемся
К великому сожалению, к чему-то более серьезному Директум сложно приспособить. Я об этом уже упомянул:
Всякие проекты интеграции спотыкаются о недостатки платформы, которая лежит в основе Директума. Даже банальное автоформирование документов в Директуме для какой-нибудь учетной системы делается с жуткими граблями и костылями, куда потом страшно залезать. Пытаешься сделать какие-нибудь интересные трюки (опять банальный пример - запрет создания версии документа, недавно на форуме обсуждалось) - ловишь ошибки Access Violation на ровном месте в каком-нибудь .bpl. Например, нужна нашим заводам система совместного проектирования и согласования чертежей. Ходил я такую схему смотреть к Сименсу - ну смешно же. У них все отличие от Директума в том, что красиво и правильно отображается взаимосвязь всяких составных деталей, плюс интеграция с рисовальщиком чертежей, плюс расчеты, при этом наличествует совершенно кошмарное Workflow.
Мне кажется, давно уже пора отдирать платформу от Директума и доводить первую до ума - давать максимально гибкие возможности модификации и интеграции. Тогда вам партнеры такие проекты смогут строить - мама не горюй.
Коллеги, только по возможности попрошу не сводить дискуссию к обсуждению самого инструмента, т.е. самой системы DIRECTUM.
Забавно, но делопроизводство пока самая редкая задача из всех моих проектов
Оооочень поспешное заявление...
Коллеги, создана тема относительно предложения от Ивана Середкина:
Ссылка на тему форума здесь.
Прошу рассказать подробнее, можно в личку.
Дополнение: или в теме на форуме.
Валентина, и за сколько по вашему мнению можно стать хорошим универсалом? Или же такое вообще не достижимо?
От себя могу добавить, что при работе на клиента DIRECTUM становишься универсалом волей-неволей. Сперва тебе приходится заниматься администрированием (обычно в процессе внедрения), потом постепенно возникает необходимость самостоятельной доработки, а самостоятельная доработка системы рано или поздно захватывает необходимость занятия бизнес-аналитикой внутри компании.
И да, действительно отсюда получается заниженная "цена" на универсала - ведь компания изначально брала его на одну работу, с одной оплатой. А то, что он осваивает весь фронт работ, хоть и постепенно, это уже считается как "производственная необходимость", не сильно повышающая оплату.
Зачем же секретничать =) Весь раздел Awards в помощь =)
Достижимо всё, но по срокам не скажу, т.к., увы, нет реальных примеров перед глазами, чтобы подбить хоть какую-то статистику. Под примерами я подразумеваю как раз не универсалов, как таковых, а хороших универсалов ^_^
Само собой хороших - ведь всегда именно к этому и надо стремиться ;) Жаль, что нет примеров. Очень интересно было бы по оценке реальных примеров составить и для себя некий примерный прогноз, план развития на будущее. А то извечный вопрос, стоит уходить в специализацию, или пытаться добиться статуса "хорошего" универсала. Метания...метания... )))
Для этого, кмк, нужно очень хорошо для себя понять и решить - важна ли внешняя рыночная оценка или главное самой считать себя мега-профи. Я не считаю, что хорошим универсалом стать сложно. Долго - да. Но не сложно. Но нужно понимать, что в конце этого пути с большой долей вероятности будет существенный разброс между самооценкой и оценкой рынком, о чём я и писала выше.
Для кого-то это неважно, а для кого-то такой путь становится бессмысленным.
Поскольку возможности системы Директум напрямую влияют на профессиональное развитие сотрудника, то прошу возможности продолжить обсуждение с Валентиной.
Я, откровенно говоря, навскидку не помню какие-то выдающиеся решения, отличающиеся, условно говоря, от процесса внедрения договоров с тем или иным количественным изменением сложности, а не качественным. Мне запомнились только инструменты Акелона, не помню, с Авордсов или нет, но они вообще ведут собственную разработку - это не включает в себя только разработку в Директуме. Приведите, пожалуйста, пару-тройку примеров с конкурсов, которые вас впечатлили.
В прошлом конкурсе меня абсолютно впечатлило решение по отелям. Причём впечатлило именно тем, что реализована задача, к ECM-системам не имеющая ровно никакого отношения.
Именно о том, что DIRECTUM - система ECM-класса и стоит в первую очередь помнить, сетуя на "ограниченность". Плотно наблюдая за Club-ом я регулярно вижу попытки решать средствами системы абсолютно нехарактерные для неё задачи. Иногда это получается действительно блестяще, как с упомянутыми мной отелями.
Да, я помню прекрасную сентенцию о том, что "когда в руках молоток - всё вокруг кажется гвоздями". Но я искренне придерживаюсь мнения, что, выбирая гвозди и молотки, стоит делать поправки "на ветер", не пытаясь вбивать крохотные декоративные гвоздики кувалдами, а сотки - пластиковыми музыкальными молоточками.
Отличный пример того, что среднестатистическому разработчику IS-Builder становится тесно в рамках DIRECTUM и карьерный его путь (это мы возвращаемся к теме поста, надеюсь, модераторы оценят) лежит вне системы (в данном случае HTML + JS, как я понимаю), если он хочет профессионально развиваться дальше. В общем, всё, что я выше говорил о возможностях системы, остается в силе.
Решение по отелям меня тоже впечатлило. Разбирая модуль управления совещаниями, а именно календарь резервирования помещений, где используются те же алгоритмы, я начал углубляться в сторону Html+ Js+Css, потому что именно эти инструменты дают в конечном итоге красивое решение поставленных заказчиком задач. Настолько гибкая и красочная по цветовой схеме настройка интерфейса происходит не на IS-Builder.
Согласен с Андреем, что is-builder становится "тесным", больший интерес появляется к SQL и .NET
Андрей, Артём, скажите пожалуйста, если вы вырастаете из любимой детской кроватки, да ещё и начинаете любить раскладушки - это кроватка плохая, неприспособленная и не отвечающая своему предназначению?
Ну уж ... DIRECTUM с детской кроваткой сравнить ... Надеюсь конкуренты такой мем не подхватят!
Дмитрий, а я и не сравнивала
Я, честно говоря, тоже увидел сравнение Директума с детской кроватью. Хотя хотелось бы, чтобы Директум ассоциировался с роскошным удобным диваном, на котором можно делать много полезных и интересных вещей и из которого трудно вырасти, потерять к нему интерес.
Вообще в "вырастании" конкретно разработчиков из Директума нет ничего хорошего - это способствует оттоку квалифицированных кадров из разработки на IS-Builder. Одно из кардинальных решений, на мой взгляд - это, как я уже писал, развитие платформы, а не Директума.
Каждый видит то, что ему хочется видеть. Тем временем на вопрос вы так и не ответили.
А проекция моя касалась не системы DIRECTUM и не платформы IS-Builder, а относилась к элементарному человеческому развитию. Эту же аналогию и аналитики на себя легко могут примерить.
Я не вижу ничего страшного в том, что человек в течение своей жизни развивается и растёт - это наоборот прекрасно. Но рост у каждого происходит по разному. Кто-то благодарен каждому опыту, обретённому на пути, понимая, что любой опыт формирует то, что есть на данный момент. А кто-то с досадой сетует на потерянное время и ругает путь за то, что был не идеально ровным и безоблачным, не осознавая, что все недостатки он видит только сейчас, уже с другой "высоты". Собственно, потому и видит.
Человек желающий найдёт тысячу возможностей - и именно это демонстрирует приведённый мною пример с реализацией решения по отелям внутри системы DIRECTUM. И именно так я лично стараюсь работать на своих проектах, выпиливая из "коробки" ажурную вязь, уникальную под каждого Заказчика.
Человек нежелающий найдёт тысячу причин. И таким людям действительно лучше сбросить тесную кожу, расправить крылья и идти дальше.
Валентина, вы говорите, что каждой задаче свой инструмент. Да, это разумно. Андрей и Артем говорят (и я с ними согласен), что инструментарий разработки в Directum не идеален. И оказывается, что правы и те и другие. Ваши (наши
) утверждения не противоречивы.
По своему опыту разработчика: У системы, как платформы для разработки, просматривается хороший потенциал. Если смотреть поверхностно, то система проста для разработки и в то же время на ней можно реализовать очень много специализированных решений, не связанных с делопроизводством...
Но, как говорят, дьявол кроется в деталях. А детали таковы:
В итоге получается, что если разработка чуть чуть упирается в "ограничения системы", то приходится такой огород городить, столько костылей втыкать, что потом сам на них не дышишь и думаешь: "каким чудом всё это ещё работает?".
И пути выхода из это ситуации я вижу 2.
Я надеюсь, что вы это не мне приписываете, иначе вы меня совсем не поняли.
Михаил вполне подробно все объяснил.
Это который? Где Директум представляется в виде детской кроватки, из которой надо вырасти?
Если компания DIRECTUM хочет вырастить сильное сообщество разработчиков, то уход в веб - опасный путь. В форуме в соответствующей теме люди пишут про взваливание функций аналитика и РП - это, как мне кажется, типичный случай развития сотрудника-разработчика у клиента компании Директум. В итоге, когда человеку-оркестру это все надоедает, он начинает искать другие пути для себя. И в том случае, если человек освоил веб-разработку, он большой долей вероятности просто уйдет в какое-нибудь сайтостроение, тем более, что зарплаты и перспективы там хорошие, вплоть, в общем-то, до Гугла с Фейсбуком.
Первый путь лучше в перспективе.
*facepalm*
И правда, зачем читать то, что пишут собеседники... Расправьте крылья, Андрей. Удачи вам.
Билдер дает возможность делать что-то дополнительное, например, разработку "красивых интерфейсов", подключая инструменты для разработки "красивых интерфейсов". И это нормально. При этом ECM-система обепечивает работу с документами, процессами для всего предприятия - и в этом функция билдера и DIRECTUM. Каждый делает свое дело.
А разработывая 20 сайт тоже можно "устать" и пойти в РП. ;)
Видимо разработчиков IS-Builder могут понять только разработчики IS-Builder. Вроде Михаил Тарасов уже по косточкам все разложил, но ведь все равно чувствуется в сотрудниках компании DIRECTUM кровная обида за родную систему. Вот только фразу из письма нашего HR я не из головы взял, есть реальная проблема, но нас не хотят слушать, обижаются.
Не все хотят пойти в РП. Вы, может быть, удивитесь, но если человек получает удовольствие от программирования, то он всю жизнь может оставаться разработчиком и получать удовольствие от своей работы.
Елена, есть объективная огромная разница между "Разработчик IS-Builder" и "Разработчик PHP (Python, Ruby, JavaScript etc)" в возможностях самореализации (это мы все еще остаемся в рамках поста), которая, откровенно говоря, убивает сообщество опытных разработчиков DIRECTUM. Это, к большому сожалению, неоспоримый факт. Мы предлагаем варианты решения этой проблемы - взгляд изнутри, но нам в ответ предлагают разобраться в разработке на IS-Builder те, кто, как я подозреваю, никогда разработкой не занимались.
Коллеги, как ваши "перепалки" по поводу "плохого" Билдера и "хорошего" Питона помогают обсуждению по сути документа? Стороны уже высказались, одна сторона видит возможности развития разработчика, другая - нет. "Гуру" тут нет, успокойтесь, а каждый разработчик выберет себе сам свой путь.
Сможете остановиться? )
Коллеги, тема уже, как рояль в кустах, поэтому поддержу Андрея Старкова, и предлагаю перейти в соответствующую тему на форуме, где можно будет весь разговор продолжить:
Тема на форуме: Карьерный гид, продолжение дискуссии
Полностью присоединяюсь к Андрею и Михаилу.
которую он выполняет отнюдь не идеально и не так, как того хочется пользователям/руководству/разработчикам. Ведь суть, как говорится, всегда кроется в деталях, часть из которых уже озвучил Михаил.
Также не может не поражать полное непонимание сотрудников Directum'а проблем прикладных разработчиков. Как-то при очередном опросе клиентов Директума я оценил систему на 4 из 10. На вопрос: "Почему?" ответил, что это из-за существенных ограничении прикладной разработки. Её удивлению не было предела, будто мы вообще говорим о совершенно разных системах.
и каждый остался при своем мнении, и ничего, к большому сожалению (и несчастью разработчиков), не изменится. Крик души прикладных разработчиков в очередной раз остался неуслышанным.
Андрей, ну уж вы то, на мой взгляд, должны были лес за деревьями увидеть... Никто, я подчеркиваю, никто не называет Билдер "плохим", иначе давно бы бросили работу с DIRECTUM. Обсуждение идет исключительно в рамках статьи, тема которой "Карьерный гид специалиста DIRECTUM". Именно с этой точки зрения обсуждается разработка в DIRECTUM и то, как она влияет на профессиональную карьеру. В рамках обсуждения непосредственные разработчики назвали несколько сторон системы, которые мешают расти по прошествии какого-то времени.
По-моему, представителей компании DIRECTUM в этой ветке можно по одним только комментариям узнать. Никто вас не ругает, вам предлагают конструктивную критику, как стать еще лучше и не терять хороших разработчиков на Билдере. Посмотрите лучше на компанию Микрософт, которая дважды (это навскидку - Виста и Восьмерка) за последнее время прислушалась к пользователям, признала свои недочеты (на слово "ошибки" опять обидитесь, наверное) и выпустила (или готовится выпустить) измененные версии.
Да вроде уже.
Всё верно. Хотя, как я понял, вот эти самые "рамки" и приводят в замешательство Андрея Курова, но пока я не понял как ему помочь (изменение платформы в расчёт не берём).
Интересно услышать мнение других разработчиков, которые уже не первый год проработали с DIRECTUM, и узнать как они выходят из этой ситуации.
Хотя не исключено, что всё дело в особенностях конкретных людей - одни могут продолжительное время заниматься схожей работой и принимать текущие ограничения (особенности, недостатки), а другим иногда хочется перемен. Не знаю.
Спасибо.
Может быть так.
Представим гипотетический бизнес-кейс: к нам, как работодателю, приходит опытный разработчик DIRECTUM, который знает особенности системы, который хочет развиваться в рамках сообщества, но не знает как. Назовём этого гипотетического разработчика Андрей К.
Он говорит, что уже многое попробовал, ударился во все возможные стенки ISBL, IS-Builder и прочих штуковин. При этом мы бы хотели, чтобы Андрей К. продолжал работать у нас и развивался дальше
Что мы ему порекомендуем?
Во! У меня вопрос к гипотетическому Андрею К.: а в чём ты видишь своё развитие? Как ты поймёшь, что развиваешься? Решение какой задачи - шаг в сторону развития? И что мешает развиваться сейчас?
Отчеты на эти вопросы помогут понять - есть ли пересечения между инструментом DIRECTUM (и решаемых им задачами) и конкретным человеком.
Грубо говоря, если человек видит своё развитие в создании сайтов, то DIRECTUM ему не поможет и его пора отпустить, а вот если в автоматизации бизнеса, то вполне может быть.
Приятно, что претензии у многих, а спрашивают гипотетического Андрея К.
Дело не в том, как видит свое развитие опытный разработчик, а в том, что в один непрекрасный момент он обнаруживает, что он перешел на стадию overqualified (этап 5 вот из этой статьи -http://habrahabr.ru/post/213939/, обязательно к прочтению для всех РП) и что в рамках DIRECTUM больше нечем заняться, кроме штампования очередного процесса, похожего на предыдущие как две капли воды. Почему нечем? Потому что рамки платформы ограничены, пример с согласованием чертежей я уже приводил. Проблемы известны - некастомизируемый интерфейс, ненастраиваемые связи - в общем все то, о чем написал Михаил и еще плюсом несколько абзацев.
В ответ на это обычно предлагают использовать обложки и контрол TWebBrowser.
Это означает изучение стека веб-технологий и потерю еще одного опытного разработчика сообществом DIRECTUM.
Что надо от программы DIRECTUM? Опять же - решение проблем, о которых говорил Михаил (про плюсом еще несколько абзацев я уже говорил).
Лично мне больше всего интересно мнение Дмитрия Тарасова, заслуженного участника сообщества. Жаль, он не высказывается.
Ну и если другие разработчики выскажутся, будет более репрезентативно.
Решил уточнить, что слово "приятно" здесь должно быть в кавычках, если это не стало понятно из исходной фразы. Реплики бросают многие, а приглашают к дискуссии меня.
Думал, пока ехал домой, и вот что надумалось. Именно в этом месте у нас разногласия. Сотрудники DIRECTUM, не ведущие разработку на реальных больших проектах, полагают, что решаемых задач у инструмента DIRECTUM вполне достаточно. Разработчики в поле (заводы, холдинги, банки и проч.), внутри так сказать, процесса, видят, что потенциала у этого инструмента намного больше его текущих возможностей. Они начинают кричать: дайте нам больше возможностей, развивайте продукт, мы сможем сделать автоматизацию бизнес-процессов еще лучше (отдельные сумасшедшие типа меня готовы кричать - давайте развиваться, потихоньку подниматься с уровня ECM до уровня ERP)! А в ответ они слышат холодное: возможностей системы предостаточно, она все умеет, мы ею довольны, и вообще вы просто не умеете ее готовить. Грустьпечаль.
Андрей, прошу прощения, если мой комментарий обидел тебя - такой цели у меня не было.
Я вижу, что тема актуальна для тебя и я действительно хочу разобраться в вопросе.
Тем не менее, я убеждён, что в других сообществах других инструментов - будь то 1С, SAP, SQL, PHP, C# - возникают подобные ситуации. Уверен, что немало людей, которые скажут, что они недовольны синтаксисом PHP, их не устраивают ограниченность 1С, они устали писать платформы для ECM систем, типа DIRECTUM на C# и они не знают как развиваться дальше.
Люди упираются в рамки. Вопрос в том на каком уровне находятся эти рамки - на уровне инструмента или сознания. Думаю, что истинна где-то по середине.
DIRECTUM не идеальный, но развивающийся инструмент. Я видел множество задач, которые были решены с его помощью, но не мало тех что ему не под силу.
Стоит отметить, что это инструмент развивается. Не всегда так, как мы это себе видим и не стой скоростью, как нам этого хочется, но развивается. У него даже DIRECTUM Club есть, где мы можем вот такие темы обсуждать (у других систем подобного я не встречал).
На мой взгляд в карьерном развитии и движении дальше поможет принятие этого инструмента таким, какой он есть. Для меня это из разряда принятия собственного тела и того факта, что я не умею летать. Многое могу, а вот летать не умею. Благо осознание этого позволило кому-то придумать самолёт, но от этого человеческое тело хуже не стало.
По поводу развития:
Развитие - это прежде всего увеличение своих способностей. И тут я вижу 2 направления. Учится делать то, что делал уже раньше "быстрее, выше, сильнее", то есть быстрее и качественнее. И второе направление - это расширение горизонтов. Научится делать то, что раньше ты не делал. С 1м направлением всё в порядке. Со вторым, довольно быстро упираемся в "рамки" системы.
Если говорим о других инструментах, то в некоторых из них достижение рамок происходит намного дольше. Кроме того, некоторые из этих инструментов расширяют свои возможности намного быстрее, чем один программист расширяет в этом инструменте свои навыки. Как пример таких инструментов: языки C#, Python и как ни странно, тот же PHP, например. При том, улучшаются они и вглубь и вширь. Появляются новые библиотеки. Появляются новые языковые возможности. Да, сравнивать языки и платформу не совсем корректно. Всё же изначально языки + библиотеки к ним предоставляют лишь базовый функционал, который ещё предстоит слепить воедино... Но в рамках рассмотрения "пути разработчика" и "возможности развития" сравнение проводить можно... И это не говоря о том, что разработка во многих средах позволяет взять и поменять целиком целый слой: Сменить язык с PHP на Python, например при разработке сайта, оставив при этом нетронутыми шаблоны и базу. Сменить базу и просто в конфиге ORM написать, что теперь мы работаем не с MySQL, а с PostgreSQL. Поменять клиентскую часть (или добавить её) реализовав её, как нативное приложение для разных ОС, например. При этом серверная часть так же остается неизменной...
В случае с Directum, на ограничения мы наталкнемся ещё на этапе задумки какого либо изменения подобного плана. Хотя, справедливости ради, стоит сказать, что в некоторых случаях реализация такого возможна "вопреки" ограничениям...
Да, у Directuma своя область применения, и зачастую всего этого и не надо. Но иногда, мы сталкиваемся с задачами, которые, казалось бы, вполне себе решаются в рамках Directuma, если не учитывать "вон ту особенность", "вот это ограничение" и "внезапно вылезший баг"...
Основная мысль разработчиков в том, что Directum развивается в основном только вширь. Появляются новые возможности для пользователей + средства управления этими возможностями для разработчиков. Старые же архитектурные решения изменяются незначительно. Хотя, стоит признать, что в том же 5.0 изменений не мало и в системной разработке. Особенно в плане интерфейса.
Я как разработчик, в данной дискуссии, на стороне Андрея Курова и Михаила Тарасова. Да, платформа весьма неплоха, но есть такие "но", что порой без костылей совсем никак не обойтись. В последнее время, даже если вижу как реализовать тот или иной функционал с помощью очередных костылей, предпочитаю просто сказать, что так сделать не получится, потому что все это уже надоело (да и не факт, что потом очередные костыли как-нибудь негативно не скажутся на производительности системы, а крайним быть как-то совсем не хочется). На мой взгляд, платформа уже давно перестала развиваться. Точнее, изменения от версии к версии то конечно были, но для прикладного разработчика особо никаких дополнительных возможностей добавлено не было. Ну, а DIRECTUM 5.0, так вообще сплошное разочарование.
Андрей правильно сказал, когда из года в год делаешь одно и то же, оно начинает надоедать. Для себя пока нашел выход в том, что переключился на разработку для веб-доступа. Обратно на ISBL возвращаться пока желания нет. Да и сколько можно топтаться на одном месте, надо двигаться дальше, изучать что-то новое.
+1
+1
+1
Границы и ограничения DIRECTUM достигнуты. Улучшаем что есть, двигаемся дальше в других направлениях :)
Иван, очень интересная и неожиданная тема получилась для ресурса, где больше говорят о технических вопросах.
Андрей, я бы хотел еще раз попытаться представить как дела обстоят с точки зрения вендора (в той мере, в которой я это понимаю, конечно).
Вы занимаетесь внедрением системы у какого-то конкретного заказчика. У заказчика есть некоторые требования к внедряемой системе, вы по мере сил стараетесь их закрыть теми средствами, которые система представляет. Иногда возможностей системы не хватает либо оказывается так, что решаемая задача в систему плохо вписывается. Вы упираетесь в ограничения и обращаетесь к вендору, чтобы он изменил систему так, чтобы решаемую задачу стало возможно решить и таким образом более полно закрыть требования заказчика. Если позволите математическую аналогию, то вы при этом ищете локальный максимум - максимальное удовлетворение требований некоторого конкретного клиента.
Вендор работает немного по-другому, в общем случае для него выгодна максимальная прибыль от всех продаж и внедрений системы, поэтому может оказаться так, что он реализует функциональность, потребность в которой обнаруживается вот в этих десяти внедрениях, но не будет реализовывать функциональность, которая нужна только вот в этом одном внедрении. В этом плане вендор как бы ищет более глобальный максимум, по крайней мере, он старается это делать, и при этом ресурсы его ограничены. Количество замечаний к платформе, например, исчисляется десятками тысяч и я боюсь, что занимаясь только ими одними команда, которая занимается разработкой платформы, потратила бы не один десяток лет только на них и никто не знает, как бы это сказалось на продажах системы, ведь появляются новые версии операционных систем, СУБД, появляются новые требования к пользовательскому интерфейсу и растут требования к производительности системы. Потребности разработчиков тоже входят в число возможных источников направлений развития системы. Но вендор вынужден выбирать какие-то определенные направления иногда в ущерб другим. А выбирая их, он вполне может и просчитаться где-то, что-то упустить из виду.
Понятно, что такое положение дел может приводить к тому, что какие-то пожелания по развитию системы вендор не будет успевать реализовывать. В свое время мысль об этом не давала мне покоя. Получалось, что у вендора есть огромное количество нереализованных возможностей по развитию системы, возникающих на конкретных проектах, которые он просто-напросто упускает. Сейчас я понимаю, что одним из преимуществ покупки готовых систем как раз является то, что из проекта в проект не приходится разрабатывать систему с нуля. Универсальную систему на все случаи жизни разработать либо невозможно, либо слишком дорого. Поэтому хорошей получается система, которая решает какую-то достаточно специализированную задачу, но при этом допускает достаточную возможность настройки и модификации, чтобы ее можно было недорого тиражировать на большое число похожих проектов. Если же систему приходится здорово затачивать под проект, то это в некотором роде нарушает законы этого бизнеса. Разработать решение для одного конкретного заказчика и разработать универсальное решение для большого числа заказчиков - это две совершенно разные задачи. Чтобы включить какой-то функционал в универсальную систему придется решать задачу именно второго типа. Это означает необходимость проектирования архитектуры, качественного тестирования и документирования. Найдутся и такие требования, которые не получится бесшовно вписать в существующую архитектуру, не порождая костыли или несовместимости, или которые невозможно реализовать в разумные сроки. Это я к тому, что не все предложения по развитию с точки зрения вендора будут осуществимы и целесообразны (но такие точно есть).
Можно ли как-то гарантировать, что какой-то функционал будет включен в очередную версию системы? Какой-то официальной процедуры, которая приводила бы к такому результату, мне неизвестно (наверно, ее нет). Но такое точно случается при определенной заинтересованности вендора в продаже или внедрении системы у конкретного клиента. В случае с аудиторией разработчиков оказать влияние на вендора тоже можно, для этого ведь и предназначен этот самый форум. Не могу ничего обещать насчет реализации функциональности, но с интересом бы выслушал срез самых топовых проблем, которые мешают жить прикладному разработчику (пока все выглядит очень удручающе).
P.S. Извиняюсь перед автором поста за то, что отклоняюсь от основной темы беседы.
срез самых топовых проблем, которые мешают жить прикладному разработчику
Авторизуйтесь, чтобы написать комментарий