Дада, я уже 7-й год исключительно теорией занимаюсь. Действительно пора заканчивать флуд на эту тему.
топикстартер: можно в личку
Зачем в личку? Думаю вопрос интересен многим.
Прямо здесь и прямо сейчас конкретно цифры вы от меня не услышите. Я её сам смутно представляю. Для чего (в том числе) и было начато это общение. Ближе к переходу проекта в "реальную плоскость" вопрос финансировани конфиденциально бум обсуждать с руководителем команды.
Касаемо моего финансово положения, то оно конечно не то, что год назад , но по украинским меркам не слабое. И немалую часть из нынешних финансовых потоков я готов инвестировать в эту тему. Так что "человекогодами" программерского труда пугать ненуна.
В первом сообщении я упоминал, что есть кое какой опыт по заказу/написанию под моё тех задание узкоспециализированного софта. Поскольку это был ПЕРВЫЙ опыт, шишек набил немало, но продукт получился весьма и весьма достойный. Но самое главное - был получен ОПЫТ работы с таким весьма специфическим контингентом как "программерская братия"
Вариант "написать бизнес-процессы, подходящие под софт" имеет ровно столько же права на существование, как и вариант "написать софт, подходящий под бизнес-процессы". Хотя об этом часто совершенно безосновательно (или с совершенно идиотскими основаниями типа "а наша бухгалтерия привыкла так щетать, и не вам ее учить) забывают...
В теории - да. На практике (в такси) - крайне сложно. Проверено.
Специфика бизнеса...
Ну, программировать - тоже, вообще-то, не слишком простое занятие. Может оказаться и посложнее, чем бизнес перестроить. Истина, впрочем, как обычно, посередине. Внедряя какое-нить ИТ с умом, приходится и это ИТ "дорабатывать напильником", и бизнес-процессы тоже.
Вот прямо сейчас попытаюсь начать систематизировать.
Цели:
1.Качественно новый уровень услуги диспетчеризации автомобилей такси. ... 2. Переход качественно иной уровень распределения заказов между водителей. ... 3. Дополнительный сервис для водителей такси. ... Х. Побочный продукт: ... ... список можно продолжить в основном за счёт "побочных продуктов" и "не задокументированных возможностей"
перечисленное - это не совсем цели, это скорее способы достижения целей. Звучавший трезвый совет - не изобретать велосипед, а доработать имеющийся процесс напильником - возможно станет понятнее, если формулировать достижимые и измеримые цели, как то: увелиить доход на n%, снизить простои до..., привлечь лучших и уменьшить текучку каров...
А пока это больше похоже на Первомайские лозунги :-)
...мне кажется, тут работа если и есть, то для бизнес-аналитика, софтовым парням пока рановато
Опис, звісно, з точки зору програмиста або менеджера проектів, але всі необхідні деталі по ходу розжовуються простою мовою, без сленгу. Варто також звернути увагу на лінки, які даються наприкінці, там теж є чимало корисного.
Уфф... Читаю, изучаю, спасибо!
Уфф... Читаю, изучаю, спасибо!
Я так вперто підсовую вам цю тему, бо переконаний, що ваша ідея вимагає саме такого підходу. Для цього є багато причин, з них я особливо б виділив дві: немає абсолютної ясності як має виглядати результат (а отже вимоги і потреби будуть інтенсивно змінюватись у процесі розробки та експлуатації проміжних версій) та немає чітко визначених термінів. На додачу такий підхід (після завершення декількох перших ітерацій) дозволяє досить точно прогнозувати витрати на реалізацію тієї чи іншої функціональності і постійно тримати процес під контролем. Що, гадаю, вам, як замовнику, буде дуже корисно. Ну і головне: знов-таки, після закінчення перших ітерацій, у руках постійно є готовий продукт, в якому працює принаймні частина необхідної функціональності, а отже ситуація, коли проект довго і нудно пишуть, а потім, коли закінчились гроші, замовник опиняється з купою непотрібних йому файлів які немає куди засунути - принципово неможлива.
Ближе к переходу проекта в "реальную плоскость" вопрос финансировани конфиденциально бум обсуждать с руководителем команды.
прежде, чем набирать команду, необходимо обсудить финансирование с потенциальным менеджером проекта, чтобы ты, как заказчик, представлял примерный уровень затрат, а PM мог набирать людей, оперируя какими-то цифрами. А чтобы ими оперировать, нужно иметь ТЗ, иначе не составишь бизнес план и не посчитаешь затратную часть (зарплаты, оборудование и аренда, если надо)
Всем большое человеческое спасибо за реальную помощь!
Уже какой день подряд ПРОСВЕЩАЮСЬ , отодвинув в сторону "текучку" Потихоньку вырисовываются контуры тех задания. Думаю, для создания относительно чёткого ТЗ потребуется ещё неделька...
прежде, чем набирать команду, необходимо обсудить финансирование с потенциальным менеджером проекта, чтобы ты, как заказчик, представлял примерный уровень затрат, а PM мог набирать людей, оперируя какими-то цифрами. А чтобы ими оперировать, нужно иметь ТЗ,
А там и к финансам перейдём.
SergiyUA, отписался в личку
для создания относительно чёткого ТЗ потребуется ещё неделька...
продолжу резонерствовать ;-)
Если оценивать очень грубо, то этап ТЗ - это примерно процентов 10. Так что либо не "еще недельку", либо то будет совсем не ТЗ
пс. я почти уверен, что ты почти уверен, что с тобой "такого" не произойдет ;-)
ппс. для сравнения прикинь ТЗ на переделку своих бизнес-процессов ;-)
Если оценивать очень грубо, то этап ТЗ - это примерно процентов 10. Так что либо не "еще недельку", либо то будет совсем не ТЗ
Согласен. Это будет "не совсем ТЗ" но уже и не "первомайские лозунги".
Крапаю под чутки руководством специалиста. Посему есть шанс причесать свои "хотелки" для уровня адекватного восприятия.
2. Ідею ставити одразу і скайп я б відсунув трохи далі у переліку пріорітетів.
Согласен. Там ного каих задумак и по любому нужно будет рисовать таблицу приоритетов.
Возможно стоит обратить внимание на готовые решения, которые используют онлайн геймеры. Например Teamspeak или Ventrilo Прелесть в том, что во-первых, эти решения не так уж сильно грузят канал (например с Тимспиком народ ухитрялся одновременно играть и разговаривать на диалапе), во-вторых, оба решения позволяют установить свою серверную часть, при этом не требуется больших мощностей.
Не так давно разрабатывали подобную программу на основе Navigon и Symbol MC35. Вполне можно и для TomTom - различия небольшие. Работает нормально под виндами 5 и 6. Отслеживает положение, статус, маршрут ... В общем-то, сложного ничего нет, у нас уже прототип тестировался вполне успешно у нескольких клиентов. Жаль, пришлось свалить, не дождавшись окончательного результата. Но и идея, и реализация на основе Symbol-ов - совершенно не сложные.
Відповісти
Поперед.
Зміст
Наступ.
Гілками
, но по украинским меркам не слабое. 
