Вы конечно отчасти правы, но писать сочинения - это и есть навык связно формулировать свои мысли. И без этого школьного фундамента во взрослом возрасте уже невозможно будет что-то выстроить. А вот когда в школе перестанут заставлять писать сочинения - тут описанный в статье процесс ускорится многократно.
Более 10 лет разрабатывал на С++, и решал множество подобных задач. И пришел к тому, что лучшее решение подобных задач - решать их не на С++, а на чем-нибудь интерпретируемом.
Понимаю, что у всех клиентов свои приоритеты, однако из своего опыта разработки, внедрения и использования различных CRM посоветовал бы следующую приоритезацию развития: 1. Интеграция CRM с бухгалтерией или банком - чтобы видеть факты прихода денег, причем с привязкой к сделкам. Потому как выполненная работа менеджера по продажам - это деньги на счёте. А менеджер - главный пользователь CRM
2. Расчёт бонусов/премий менеджерам. Поддержка разных расчетных алгоритмов или даже скриптов. Так чтобы менеджер в любой момент видел сколько он наработал в этом месяце.
3. Интеграции с почтой, мессенджерами, телефонией - чтобы видеть и слышать всю историю сделок и отношений с клиентом
4. Раз уж CRM для B2B хорошо бы иметь функционал длинных многоэтапных продаж, многоэтапных работ с актированием. Планы расходов и поступлений денег по уже законтрактованным работам.
6. Что касается аналитики, разработать в рамках CRM действительно мощную аналитическую систему - крайне сложная и объемная задача. На мой взгляд лучше обеспечить удобные способы интеграции с внешними системами. Начать можно хоть с выгрузки в csv/xlsx.
7. Календари для встреч и задач на мой взгляд незкоприоритетны, т.к. сотрудники уже наверняка имеют календарь в почтовом клиенте. Два календаря - это скверно.
Помнится, на курсах MBA рассказывали, что любая организация размером >N человек, без грамотного управления, способна полностью зациклиться на внутренних вспомогательных задачах, не выдавая вообще никакого продукта наружу. Да еще так, что все сотрудники реально заняты оказываются. При внешнем финансировании, разумеется. И даже приводили пример какого-то НИИ, про который "забыли" на много лет, а он продолжал существовать фактически не делая вообще ничего для кормящей его страны.
Это да. Сейчас прочностно-тепловой расчёт в САПРе делается за считанные минуты одним человеком. А раньше целые отделы годами это считали. То же самое с аэро-гидродинамическим моделированием. И это в бесплатном(!) Фрикаде, который ещё даже до 1й версии не дошёл!
И поэтому категорически не укладывается в голове, почему в 60-80е строили и запускали орбитальные станции и Буран, придумывали ионные двигатели, а сейчас, со всем могуществом современных технологий, едва в состоянии серийные Союзы на готовую МКС закидывать
В 2005 году на рынок вышла система управления версиями Git, которая позволила отслеживать изменения в коде и управлять различными версиями проектов, а чуть раньше разработали подход Agile. Все это способствовало улучшению взаимодействия внутри команд, однако попытки автоматизировать разработку долгое время оканчивались ничем.
Системы управления версиями исходников появились гораздо раньше гита. Как минимум в 1972 году (SCCS), а может и раньше. Разумеется, Git поднял это все на новый уровень и стал стандартом отрасли, но основные идеи уже были реализованы задолго до него.
Как только мы что-то выбираем, мы становимся заложниками того, чем пользуемся. Но! Какой из этого вывод? А то, что нужен какой-то специализированный язык для создания таких систем ("движок") и набор трансляторов на различные платформы и стеки.
Звучит страшновато. Не лучше ли выбрать, например, формат SVG? Или HTML+CSS. А трансляцию в стекозависимый вариант, ручную или автоматическую, оставить уже на совести проектной команды. Всяко такой подход уже упростит им жизнь.
через 2 года вы попадете в точку в которой надо будет ее переписывать
Боюсь, через такой срок мы туда попадем, даже если выделим на это специальную команду
> И очень трудно будет заставить команду у которой в KPI стоит вовремя сдать очередной релиз Нужен такой процесс наполнения системы, чтобы он не создавал отдельной проектной команде никакой нагрузки, а наоборот, экономил время: допустим, у команды в спринте есть задачи запилить красную и зеленую кнопки: 1. Смотрим в общем репозитории элементов 2. Красной кнопки нет. Делаем в соответствии с общими гайдами на кнопки(если он есть): шрифт, скругления. Заливаем в общую репу эту красную кнопку. 3. Зеленая кнопка в общей репе есть - берем оттуда готовую.
Да, через пару лет эта общая репа потребует серьезной ревизии, но это куда меньше работы, чем делать все с нуля, собирая требования с действующих и планируемых проектов.
Тема абсолютно верная, несмотря на "внушительные" названия типа "ядро", бигдата, сервисы, бизнес-логика, кластеры и прочий бэкенд, именно UI по прежнему съедает бОльшую часть дорогих ресурсов вашей команды
Но agile никто не отменял, не обязательно сразу пилить всю СИСТЕМУ, сделайте хотя бы сборник дизайна типовых элементов UI, без привязки к стеку. Это уже сразу сэкономит десятки дорогих человеко-часов.
Далее, придумайте правила, регламенты, как наращивать эту систему маленькими шажками, экологично, командами действующих проектов, без привлечения выделенных ресурсов. Через год-два глядишь и будет уже что-то серьезное.
Вы конечно отчасти правы, но писать сочинения - это и есть навык связно формулировать свои мысли. И без этого школьного фундамента во взрослом возрасте уже невозможно будет что-то выстроить.
А вот когда в школе перестанут заставлять писать сочинения - тут описанный в статье процесс ускорится многократно.
Спасибо инертности традиционной системе начального образования, писать, да еще и рукой, еще долго будут заставлять.
Более 10 лет разрабатывал на С++, и решал множество подобных задач. И пришел к тому, что лучшее решение подобных задач - решать их не на С++, а на чем-нибудь интерпретируемом.
Больше разных CRM рынку!
Понимаю, что у всех клиентов свои приоритеты, однако из своего опыта разработки, внедрения и использования различных CRM посоветовал бы следующую приоритезацию развития:
1. Интеграция CRM с бухгалтерией или банком - чтобы видеть факты прихода денег, причем с привязкой к сделкам. Потому как выполненная работа менеджера по продажам - это деньги на счёте. А менеджер - главный пользователь CRM
2. Расчёт бонусов/премий менеджерам. Поддержка разных расчетных алгоритмов или даже скриптов. Так чтобы менеджер в любой момент видел сколько он наработал в этом месяце.
3. Интеграции с почтой, мессенджерами, телефонией - чтобы видеть и слышать всю историю сделок и отношений с клиентом
4. Раз уж CRM для B2B хорошо бы иметь функционал длинных многоэтапных продаж, многоэтапных работ с актированием. Планы расходов и поступлений денег по уже законтрактованным работам.
6. Что касается аналитики, разработать в рамках CRM действительно мощную аналитическую систему - крайне сложная и объемная задача. На мой взгляд лучше обеспечить удобные способы интеграции с внешними системами. Начать можно хоть с выгрузки в csv/xlsx.
7. Календари для встреч и задач на мой взгляд незкоприоритетны, т.к. сотрудники уже наверняка имеют календарь в почтовом клиенте. Два календаря - это скверно.
А я всегда думал что социализм - это когда высокие госрасходы (и соответственно налоги) прежде всего на социальную сферу. Как в Швеции.
Бог с вами, какой еще этап проектирования, да еще и с детализацией до UI-контролов. Все давно по Agile'у живут.
"Часть комнады, часть корабля" (с)
Да практически в любом бизнесе такие люди есть
И первые, видимо, со временем превращаются во вторых, за редкими исключениями
Помнится, на курсах MBA рассказывали, что любая организация размером >N человек, без грамотного управления, способна полностью зациклиться на внутренних вспомогательных задачах, не выдавая вообще никакого продукта наружу. Да еще так, что все сотрудники реально заняты оказываются. При внешнем финансировании, разумеется. И даже приводили пример какого-то НИИ, про который "забыли" на много лет, а он продолжал существовать фактически не делая вообще ничего для кормящей его страны.
Но в структурах Роскосмоса сотни тысяч человек работают. Хотите сказать, в основном это бесполезный балласт?
И поэтому категорически не укладывается в голове, почему в 60-80е строили и запускали орбитальные станции и Буран, придумывали ионные двигатели, а сейчас, со всем могуществом современных технологий, едва в состоянии серийные Союзы на готовую МКС закидывать
Системы управления версиями исходников появились гораздо раньше гита. Как минимум в 1972 году (SCCS), а может и раньше. Разумеется, Git поднял это все на новый уровень и стал стандартом отрасли, но основные идеи уже были реализованы задолго до него.
Звучит страшновато. Не лучше ли выбрать, например, формат SVG? Или HTML+CSS. А трансляцию в стекозависимый вариант, ручную или автоматическую, оставить уже на совести проектной команды. Всяко такой подход уже упростит им жизнь.
Боюсь, через такой срок мы туда попадем, даже если выделим на это специальную команду
> И очень трудно будет заставить команду у которой в KPI стоит вовремя сдать очередной релиз
Нужен такой процесс наполнения системы, чтобы он не создавал отдельной проектной команде никакой нагрузки, а наоборот, экономил время: допустим, у команды в спринте есть задачи запилить красную и зеленую кнопки:
1. Смотрим в общем репозитории элементов
2. Красной кнопки нет. Делаем в соответствии с общими гайдами на кнопки(если он есть): шрифт, скругления. Заливаем в общую репу эту красную кнопку.
3. Зеленая кнопка в общей репе есть - берем оттуда готовую.
Да, через пару лет эта общая репа потребует серьезной ревизии, но это куда меньше работы, чем делать все с нуля, собирая требования с действующих и планируемых проектов.
GTD вам в помощь
Тема абсолютно верная, несмотря на "внушительные" названия типа "ядро", бигдата, сервисы, бизнес-логика, кластеры и прочий бэкенд, именно UI по прежнему съедает бОльшую часть дорогих ресурсов вашей команды
Но agile никто не отменял, не обязательно сразу пилить всю СИСТЕМУ, сделайте хотя бы сборник дизайна типовых элементов UI, без привязки к стеку. Это уже сразу сэкономит десятки дорогих человеко-часов.
Далее, придумайте правила, регламенты, как наращивать эту систему маленькими шажками, экологично, командами действующих проектов, без привлечения выделенных ресурсов. Через год-два глядишь и будет уже что-то серьезное.
Полгода думал периодически над этим вопросом, полагаю что абстракций все же не существует. Почему? По-определению понятия "абстракция" ))
Похоже, вы на пути изобретения паттерна Фабрика, но путь еще до конца не пройден.
Нажмите любую буквенную клавишу - и узнаете )
Русского в списке нет, но он все-таки поддерживается, судя по статье?