Я разрабатываю веб-приложения для автоматизации учета и бизнес-процессов на платформе SkyBase. Пожалуй, платформа больше заточена под учетные решения, но был у меня и опыт создания на ней полноценного рабочего бизнес-процесса для юридической компании (некоторая информация и скриншоты есть здесь). Забавно, что заказчик изначально предложил для моделирования процесса BizAgi Process Modeler, который вы в числе прочих инструментов рассматриваете в своей статье. Однако потом оказалось, что он его использует просто как удобный способ рисования картинок, а запустить симуляцию построенного процесса невозможно, т.к. это не процесс, как он задуман в BizAgi, а просто набор картинок, которые по какой-то причине показались заказчику подходящими для иллюстрации процесса и которые удобно расставлять в нужной последовательности.
Если найдете желающих активно пользоваться этим сервисом, то тогда имеет смысл его делать, и программистов при желании найти можно. Главное, чтобы существовала не только проблема, но и желающие ее решать, а не просто покивать головой «да, есть проблема».
Скажите, а знакомые, которым идея не понравилась, сами рыбаки? Если нет, то, наверное, им сложно будет понять смысл такого сервиса. Попробуйте поинтересоваться мнением не знакомых, а тех, кому тема близка. У меня среди знакомых есть всего один рыбак — он о такой проблеме ни разу не говорил.
Это онлайн конструктор приложений для автоматизации бизнес-процессов и создания учетных систем. Примерами таких приложений могут быть различные CRM, система приема и обработки заявок, система подбора недвижимости, учет договоров и т.д. Один из примеров можно посмотреть в этом видео.
Цель проекта — создать удобный инструмент для разработки приложений указанного класса, позволяющий минимизировать затраты (времени и денег) на разработку за счет наличия мощных протестированных функциональных блоков и возможности гибкой настройки приложения. В идеале (до которого пока далеко :)) создать приложение сможет человек, не обладающий навыками программирования, а просто понимающий, какой бизнес-процесс он хочет автоматизировать.
Проект коммерческий, планируется зарабатывать на абонентской плате за хостинг приложений.
Возможно. Некоторые вещи надо сначала попробовать, чтобы понять, удобно это или нет. Пока не пробовала, кажется, что куча одинаковых по цвету иконок будут сливаться и затруднять выделение нужной, но может и нет. Кстати, если они будут отсортированы по цвету и (в рамках цвета) по алфавиту, то можно зрительно запомнить цвет плюс относительное положение на экране среди других иконок того же цвета — тогда быстро найдется :)
Мне кажется, что ищешь не столько по цвету, сколько по общему виду картинки. Да, наверное, цвет первым бросается в глаза — но только в случае, когда ситуация примерно как на скриншоте (3 красных, 4 зеленых и т.д.). Если же будет весь экран заполнен, например, зелеными иконками — вряд ли это поможет в поиске нужной — придется внимательно вглядываться в каждую.
Мой совет: не работайте с коэффициентом меньше 1.3-1.5x от себестоимости
Тут, наверное, смотря что называть себестоимостью… Можно ведь в себестоимость заложить возможные риски — главное, не перестраховаться настолько, что цена получится заоблачной.
Ну, и нужно уметь останавливать поток пожеланий заказчика:
«В ТЗ, на основе которого мы договорились делать проект, сказано про танцующих розовых слоников? Нет? Значит, их не будет. Или будут, но за отдельную плату в размере Х рублей — оплатите, пожалуйста, счет.»
Как правило, после таких слов заказчик спускается на землю и осознает, что не так уж ему этого и хотелось. Если же пожелание действительно важное, а вы уже проявили себя как профессионал, то почему бы и не продолжить сотрудничество с вами.
Мне понравился подход одного дизайнера, с которым недавно работали: на просьбу рассказать до начала работ хотя бы примерно, как всё будет выглядеть, он отвечает, что у него уже есть в голове хороший вариант, но описывать его словами не имеет смысла — надо брать и делать. Хороший способ заинтриговать заказчика, который не может четко сформулировать, что хочет.
Возможно, вы говорите о более поздней стадии — когда проект уже взят в работу и идет дальнейшее (уже оплачиваемое) обсуждение деталей его реализации. В этом случае, конечно, есть инструменты для ведения проекта и взаимодействия с заказчиком. Но применять такой подход на стадии, когда на заказ претендуют 20 человек, и вероятность получить проект пусть не 1/20, но всё равно не более 1/5, считаю преждевременным.
Верно. Только я постаралась еще определить оптимальный размер этих кусочков :) Понятно, что целиком слона не проглотить, но если делить его на слишком мелкие кусочки, кто-то может вас опередить, и тогда есть будет нечего.
2. Оценивайте задание исходя из опыта решения прошлых задач.
Когда прошлый опыт есть в достаточном количестве, то советы, наверное, уже будут не нужны — если за это время не сформируется формальный алгоритм определения цены проекта, то хотя бы «чуйка» появится, позволяющая выдать оценку в нужном диапазоне. Целью моего анализа было дать какую-то отправную точку тем, кто только начинает самостоятельно определять стоимость своей работы.
Если удалёнку воспринимать как «возможность выбирать, где работать — дома или в офисе», то мне она определенно нравится. Сейчас ситуация такова, что я могу выбирать, где работать. И, как правило, я с утра работаю дома — разгребаю почту, решаю задачи, не требующие обсуждения с коллегами, и планирую задачи, требующие обсуждения, а затем еду в офис и до конца дня работаю там. Иногда бывают случаи, когда в течение всего рабочего дня требуется активное взаимодействие в команде — тогда могу приехать в офис с утра. Бывает и наоборот — задачи у каждого свои, обсуждение не требуется, а требуется, наоборот, тишина и концентрация на своей работе — тогда могу весь день провести дома.
Однако мне кажется, что настоящая удалёнка — это всё же другое. Это работа без личных встреч с людьми, причем не потому, что так кому-то хочется, а потому, что нет возможности (или невыгодно) встречаться лично. В таком режиме я работаю с большинством заказчиков. Меня это вполне устраивает — все срочные вопросы можно оперативно решить по телефону или по скайпу, а непосредственно разработкой можно заниматься и без присутствия рядом с заказчиком. Заказчики, которым важен результат (а не демонстрация напряженной работы) тоже довольны. Но такие отношения не исключают обычную работу в офисе — у меня с коллегами и у заказчика с его сотрудниками.
Мой проект — SkyBase.
Это онлайн конструктор приложений для автоматизации бизнес-процессов и создания учетных систем. Примерами таких приложений могут быть различные CRM, система приема и обработки заявок, система подбора недвижимости, учет договоров и т.д. Один из примеров можно посмотреть в этом видео.
Цель проекта — создать удобный инструмент для разработки приложений указанного класса, позволяющий минимизировать затраты (времени и денег) на разработку за счет наличия мощных протестированных функциональных блоков и возможности гибкой настройки приложения. В идеале (до которого пока далеко :)) создать приложение сможет человек, не обладающий навыками программирования, а просто понимающий, какой бизнес-процесс он хочет автоматизировать.
Проект коммерческий, планируется зарабатывать на абонентской плате за хостинг приложений.
Ну, и нужно уметь останавливать поток пожеланий заказчика:
«В ТЗ, на основе которого мы договорились делать проект, сказано про танцующих розовых слоников? Нет? Значит, их не будет. Или будут, но за отдельную плату в размере Х рублей — оплатите, пожалуйста, счет.»
Как правило, после таких слов заказчик спускается на землю и осознает, что не так уж ему этого и хотелось. Если же пожелание действительно важное, а вы уже проявили себя как профессионал, то почему бы и не продолжить сотрудничество с вами.
Когда прошлый опыт есть в достаточном количестве, то советы, наверное, уже будут не нужны — если за это время не сформируется формальный алгоритм определения цены проекта, то хотя бы «чуйка» появится, позволяющая выдать оценку в нужном диапазоне. Целью моего анализа было дать какую-то отправную точку тем, кто только начинает самостоятельно определять стоимость своей работы.
Однако мне кажется, что настоящая удалёнка — это всё же другое. Это работа без личных встреч с людьми, причем не потому, что так кому-то хочется, а потому, что нет возможности (или невыгодно) встречаться лично. В таком режиме я работаю с большинством заказчиков. Меня это вполне устраивает — все срочные вопросы можно оперативно решить по телефону или по скайпу, а непосредственно разработкой можно заниматься и без присутствия рядом с заказчиком. Заказчики, которым важен результат (а не демонстрация напряженной работы) тоже довольны. Но такие отношения не исключают обычную работу в офисе — у меня с коллегами и у заказчика с его сотрудниками.