Rambler's Top100
E-xecutive

Executive MBA Школы менеджмента Университета Антверпена
• Набор. Обучение без отрыва от бизнеса в России. Занятия в центре Москвы.
• Рейтинг Financial Times. Входит в первую 20-ку МВА в Европе.
• Персональный коучинг, обновление знаний, обмен опытом.
День открытых дверей 04.10.14. Регистрация
Разделяем валютные риски клиентов.

Автоматизация офисной деятельности - разговор начистоту


Перейти в список форумов Форумы
Обновления Обновления
Перейти в список тем этого форума Список тем
Поиск Поиск
Помощь Помощь
Авторизация Войти
Регистрация

  Участник сообщества      3608  
 - 10.04.10 3:04
10 лет я занимался автоматизацией офисной деятельности -- в основном туристической (хотя были и другие проекты).

Ухожу из этой профессии с выигрышным счётом 7:4 (есть шанс в лету изменить счёт на 8:3). Займусь менее нервными проектами. Да уже занимаюсь...

И вот я беру на себя смелость утверждать: почти всё, что пишется об автоматизации офисной деятельности -- ерунда.
Удивляться нечему -- пишут же автоматизаторы (больше ж некому!). Боюсь, правда им не нужна. Ну кроме той, что автоматизация -- дорогое удовольствие.

В этом сообщении я изложу только самые важные свои тезисы, к которым пришёл. Если тема будет интересна - ещё подкину.

Так начнём же повесть сию...

1. Когда нужна автоматизация?
Только когда есть шанс с её помощью увеличить производительность труда хотя бы в разы.

Если Вы не собираетесь расти -- автоматизация вам не нужна.

2. Не нужно писать так называемое ТЗ -- нет в этом смысла

Наверное, этим тезисом я возмутил многих. Поэтому спрячусь за широкую спину Фредерика Брукса:

«Правда заключается в том, что клиенты не знают, чего хотят. Обычно они не знают, на какие вопросы нужно дать ответ, и почти никогда не задумываются над задачей настолько детально, как это нужно указать в спецификации...

Я пойду дальше и стану утверждать, что на практике клиенты, даже вместе с инженерами-программистами, не в состоянии указать полно, строго и корректно точные требования к современному программному продукту, прежде чем будут созданы и опробованы какие-либо версии продукта, спецификации к которому они составляют»
(Фредерик Брукс «Мифический человеко-месяц, или как создаются программные системы», глава 16).

Весь мой опыт говорит, что Брукс прав.

3. Крайне важно внимательно посмотреть на других -- как они автоматизировались?

А вот это многие сочтут банальностью. Если не акцентировать внимание на слове "внимательно".

Оно означает, что нужно узнать всё, что можно -- в идеале понаблюдать за работой "автоматизированного" сотрудника и побеседовать с ним в неформальной обстановке.

4. Софт должен быть изменяем
Это второй вопрос, кто и как будет менять софт. Важно, чтоб у руководителя была такая возможность.

Иначе - провал почти наверняка.

5. Судьба внедрения -- в руках сотрудников
Если сотрудники придут к убеждению, что работа с программой нецелесообразна -- внедрение не состоится.

Поэтому самое важное -- убедить их, что внедрение осуществляется и в их интересах тоже. И убеждать нужно не словами - а отработкой их замечаний.

* * *

P.S. Просьба к тем, кто лично не участвовал в проектах по автоматизации: не делать утверждений. Пишите вопросы и предположения: поверьте, теория и практика в данном вопросе имеет мало общего.
  Участник сообщества  Анатолий Юмашев    167  
 - 10.04.10 7:22
Цитата
Юрий Максименко пишет:
И вот я беру на себя смелость утверждать: почти всё, что пишется об автоматизации офисной деятельности -- ерунда.

это да )
1. и думаю что ваш и мой пост относится к этой же категории )))
1.1. мысль выраженная словами есть ложь (с) кто то из великих
1.2. потому все слова написанные кем либо кроме вас есть ложь
Цитата
Юрий Максименко пишет:
1. Когда нужна автоматизация? Только когда есть шанс с её помощью увеличить производительность труда хотя бы в разы.

Если Вы не собираетесь расти -- автоматизация вам не нужна.

2. все верно.
2.2. но есть еще одна цель - качество. у ИТ всего 2 преимущества: производительность и качестве конечного результата.
вот хороший материал на эту тему: В поисках эффективности ИТ
http://www.iemag.ru/analitics/detail....〈=ru
http://www.iemag.ru/analitics/detail.php?ID=18884
http://www.iemag.ru/analitics/detail....〈=ru
p.s. материал есть исключение из правила №1 smile:)

Цитата
Юрий Максименко пишет:
2. Не нужно писать так называемое ТЗ -- нет в этом смысла

Наверное, этим тезисом я возмутил многих. Поэтому спрячусь за широкую спину Фредерика Брукса:

«Правда заключается в том, что клиенты не знают, чего хотят. Обычно они не знают, на какие вопросы нужно дать ответ, и почти никогда не задумываются над задачей настолько детально, как это нужно указать в спецификации...

Я пойду дальше и стану утверждать, что на практике клиенты, даже вместе с инженерами-программистами, не в состоянии указать полно, строго и корректно точные требования к современному программному продукту, прежде чем будут созданы и опробованы какие-либо версии продукта, спецификации к которому они составляют» (Фредерик Брукс «Мифический человеко-месяц, или как создаются программные системы», глава 16).

Весь мой опыт говорит, что Брукс прав.

3. Из ТЗ мне приходилось только читать примеры и гос.стандарты. Бруксов не читал smile:)
3.1. И на первой 10-ке своих проектов думал также. Мол нафига ТЗ когда у людей все равно свои тараканы в голове?
3.2. И вот теперь возвращаемся к моему п.1.1. А что есть ТЗ с вашей точки зрения? Спорим что она 100пудов отличается от моей? )
3.3. На первых проектах я думал что в ТЗ нужно фиксировать требования к программному продукту. Мол какие формы, функции, чего делать должна уметь, на каких серверах сидеть и т д.
А потом когда начал сомневаться в полезности этого документа, задумался о его значении и поставил под сомнение свои способности правильной интерпретации этого понятия и его применения.
И вот чего нашел:
- Техника - все то что сделано человек и не существовало до него в природе
- Задание - описание действий
- ТЗ - описание действий по созданию чего либо человеком.
Догоняете? smile:) Есть тут хоть одно слово о программе или компьютере?
Беда многих начинающих внедренцев в том что у них есть только примеры ТЗ на разработку. Им не от куда узнать о том что ТЗ на внедрение программы и ТЗ на разработку программы это два совершенно разных ТЗ. Такие же разные как юридические услуги и эротический массаж.
А теперь цели:
- описать структуру программного продукта. банально! и тут то ошибка! именно такие ТЗ никуда не годны для внедрения. толку от них мало и даже больше вреда.
- описать цель и порядок действий, ключевые требования, так чтобы можно был более или менее надежно зафиксировать как объем задач, ресурсов, так и их стоимость. чтобы у заказчика было во-первых понимание того че там написано, а во вторых отсутствовала двоякая возможность понимания результатов. Вот эту цель мы спокойно реализуем в ТЗ на 1-2 страницы в большинстве проектов, и на 10-20 страниц если проект большенький. В результате заказчик точно знает что он получит, мы точно знаем сколько это будет стоить и что для этого нужно.

Тут самое важное, не ставить цель описания программки, а ставить цель фиксации ожиданий заказчика, во избежание конфликтов от недопопнимания и нарушения ожиданий. Чуете разницу? Это я понял уже где то после 20-го своего проекта по автоматизации smile:) Примерно в тоже время я столкнулся с системами СМК (ISO 9000), соединил два этих знания и получил такой вот вывод. Хотя того же эффекта можно добиться обычным письмом или ком.предложением, но ТЗ как то понятней и удобней.

Цитата
Юрий Максименко пишет:
3. Крайне важно внимательно посмотреть на других -- как они автоматизировались?

А вот это многие сочтут банальностью. Если не акцентировать внимание на слове "внимательно".

Оно означает, что нужно узнать всё, что можно -- в идеале понаблюдать за работой "автоматизированного" сотрудника и побеседовать с ним в неформальной обстановке.

при том что сегодня потребность в разработке специальных программ отсутствует в 99% случаев, то это достаточно простое действие по которому идет большая часть заказчиков, если им в голову мути не подмешают )
хотя бывает и так, что нужно рискнуть и проэкспериментировать. тоже встречался.
Цитата
Юрий Максименко пишет:
4. Софт должен быть изменяем Это второй вопрос, кто и как будет менять софт. Важно, чтоб у руководителя была такая возможность.

Иначе - провал почти наверняка.

Может быть. Хотя далеко не во всех случаях. И в случае если мы имеем дело с программой массового потребления или программой которая поддерживает функции часто меняющихся процессов (НК РФ и 1С), то практически всегда выгоднее брать программу в коробочном варианте с централизованной поддержкой. Ее изменение и обновление выйдет в 10-ки раз выгоднее. И если у этой программы будет возможность самостоятельного изменения то тогда считай в двойном выигрыше. Брать самопись или деревянную коробку это две крайности одной сущности ((с) Д.Воробей, П.К.М), которых нужно стараться избегать, и брать только осмысленно понимая все но и если.
Цитата
Юрий Максименко пишет:
5. Судьба внедрения -- в руках сотрудников Если сотрудники придут к убеждению, что работа с программой нецелесообразна -- внедрение не состоится.

Поэтому самое важное -- убедить их, что внедрение осуществляется и в их интересах тоже. И убеждать нужно не словами - а отработкой их замечаний.

Я бы скорректировал. Сотрудники лишь пешки. Судьба внедрения в руках руководителя организации и руководителя проекта.
У меня есть опыт внедрения похожей системы в похожих 10 организациях. Пропорции сопротивляющихся, и поддерживающих сотрудников были одинаковы. Отличалось лишь отношение руководителя к системе. Там где у руководителя был интерес, там система запускалась на ура, а там где руководителю это было мало интересно, система просто затухала. Правда выше был еще один руководитель, которому это не понравилось, он снял головы в тех организациях где система втухла, поставил туда новые головы и система стартанула. Прикольный опыт, мне повезло участвовать в том проекте, многое понял про автоматизацию )
Убеждать можно отработкой замечаний, если есть на то бюджет ) а когда бюджет резко ограничен, то в ход идет личное обаяние и НЛП )))
Цитата
Юрий Максименко пишет:
P.S. Просьба к тем, кто лично не участвовал в проектах по автоматизации: не делать утверждений. Пишите вопросы и предположения: поверьте, теория и практика в данном вопросе имеет мало общего.

около 50 проектов, более 40 организаций. самые разные системы, от учетных типа 1С, и биллингов, до эл.документооборота, CRM и ITSM.
потянет? )
  Участник сообщества      3608  
 - 10.04.10 11:25
Цитата
Анатолий Юмашев пишет:
у ИТ всего 2 преимущества: производительность и качестве конечного результата.

Есть много случаев (с ходу вспомню свой родной туризм), когда автоматизация если вообще влияет на качество конечного продукта, то крайне слабо.

Цитата
Анатолий Юмашев пишет:
А что есть ТЗ с вашей точки зрения?

Документ, на основании которого можно сделать объективный вывод: выполнено задание или нет
Цитата


Анатолий Юмашев пишет:
при том что сегодня потребность в разработке специальных программ отсутствует в 99% случаев,

Не согласен. Есть ряд отраслей (опять же мой родной туризм), в которых "тема не раскрыта" серийными программами.

Цитата
Анатолий Юмашев пишет:
Сотрудники лишь пешки.

Когда планировалось моё последнее внедрение, руководитель фирмы корректировал рабочую версию программы. И комментировал свои правки так: "Всё логично и правильно, но не будут они этого делать".

На админ. ресурсе можно продержать внедрение месяца два. А потом, если сотрудники найдёт систему в целом вредной -- внедрение сойдёт на нет независимо от воли руководства.

Цитата
Анатолий Юмашев пишет:
Правда выше был еще один руководитель, которому это не понравилось, он снял головы в тех организациях где система втухла, поставил туда новые головы и система стартанула.


Обычно это означает, что "снятые головы" пострадали за правду. А новые учли этот опыт -- и начали выдавать желаемое за действительное.

Мы оба лжём, и оба это знаем,
Какая странная и грустная игра,
Ведь мы давно так ясно понимаем,
Что кончить прошлое пора!
  Участник сообщества  Евгений Кочуров    357  
 - 10.04.10 13:53
Цитата
Юрий Максименко пишет:
1. Когда нужна автоматизация? Только когда есть шанс с её помощью увеличить производительность труда хотя бы в разы.

Если Вы не собираетесь расти -- автоматизация вам не нужна.

Юрий, отсюда и ниже Вы пишете о системах автоматизации, предназначенных для повышения производительности конечных пользователей.

А как же быть с системами поддержки принятия решений и вообще всеми системами, которые нужны для руководителей, а не для исполнителей? Часто внедрение таких систем снижает производительность труда рядовых исполнителей. Как следствие - вызывают протест последних. Скажете, что не нужны такие системы?

Что касается ТЗ, то тут соглашусь с Анатолием: ТЗ на внедрение - очень полезная штука. ТЗ, фиксирующее детальные требование к ПО, редко когда имеет смысл, но тем не менее, иногда имеет! Например, когда интегрируются несколько систем и в разработке коннекторов задействованы несколько подрядчиков - Вы никуда не денетесь от ТЗ, фиксирующего спецификации API, без него подрядчики просто не смогут договориться.
+11
  Эксперт  Валерий Корчевский    1653  
 - 10.04.10 20:43
Цитата
Юрий Максименко пишет:...Так начнём же повесть сию...

Спасибо, Юрий, за смелость в поднятии ТАКОЙ темы.
Я своих тараканов, пока, не научил ходить строем, поэтому учусь ...
Прежде всего, позвольте высказать мнение, что предложенный тезисы описывают ОДНУ ИЗ ипостасей автоматизации. Затрудняюсь даже сформулировать ее определение, но вижу, что "автоматизация бывает разная: жидкая и газообразная".
Принимал участие в такого рода проектах:
1. Другие руководители всё знают о своих фирмах, а я, как лох - ничего.
Результат, очевидно, предсказуем. Автоматизация была нужна КАЖДОМУ учредителю, но ... своя. Когда пришло понимание того, что автоматизация делает деятельность ВСЕХ прозрачной - проект свернули.
Это в подтверждение Вашего пункта 5. Автоматизация не только не была нужна сотрудникам, но и вредна для ТОПов.

2. Как зарабатывать деньги - я знаю, но хочу понять все механизмы бизнеса (фармакологическое обеспечение зоо-ветеринарии). В связи с неописанностью бизнес-процессов модель управления так и не была сформулирована. В результате так и остались существовать 2 учета (по-большому и по-малому), т.к. совместить в единую понятийную категорию оборот канистры препарата с дилером и и флакончика с собственной вет-аптекой - не удалось.
Это вопрос к пункту 2. ТЗ, возможно, и не нужно, но чего-то подобного - не сотворили.

3. 3 десятка "типа-топов" (исполнительные руководители на региональных площадках) совсем от рук отбились. Не докладывают вовремя, несвоевременно реагируют на указания центра (металлотрейдеры) по ценовой политике. Нужно что-то делать. Откуда-то появилось лицо еврейской национальности (как я потом буду ему благодарен!!!) и "втулило" генералу тысяч за 5 тысяч американских денег нелицензионный Лотус (с клиентами), на почтовой службе которого был реализован обмен информацией между сотрудниками (в т.ч. и с "типа-топами"). Меня подключили на этапе тестирования выполненной работы ... Посидели мы с "разработчиком", поняли друг-друга (у него жена на сносях была) и вместе написали "Руководство ...", из которого получалось, что выполнено всё, что было ВЫСКАЗАНО. Переждал я недельку (на меня возложили администрирование и РАЗВИТИЕ проекта), ускоренно "мотаясь"по поисковикам, читая купленную книжку и восстанавливая в памяти процедуры делопроизводства на ракетном заводе, и начал допрос с пристрастием генерального. Что имелось в виду? Как было заказано? Что хочется? Как видится? В конечном итоге нашел ИнтерТраст, познакомился с их разработками и предложил их руководству. Был направлен в Москву на курсы, которым цены нет (для меня). В результате был принят в штат программист под Лотус и система ЗАРАБОТАЛА. Правда, выгоды (материальной) от нее я не усматриваю. Какая разница, каким инструментом руководитель не умеет пользоваться. Кнутом, пряником или Лотусом...
ТЗ, в данном проекте - стабильная работа написателю до пенсии (можно и детям эстафету передать). В принципе - возможно (наверное), в жизни - лучше без него. По мере востребованности функций. Среднее звено во внедрении автоматизации документооборота подвоха для себя не увидело, а у рядовых - никто не спрашивал.
4. Что-то маловато прибыли у меня. Нутром чую, что воруют, а поймать - не могу.
Единственный раз мной был получен карт-бланш на реализацию. Учитывая высочайшую ответственность (Заказчик мог и убить) разработал ДЛЯ СЕБЯ конечное состояние производства, информационное обеспечение которого я в состоянии обеспечить, и вперед. Единственный у меня проект, когда:
1. Автоматизация была необходима для развития;
2. Вместо ТЗ (как идти) был проработан для себя конечный образ (к чему прийти), с понимаемыми этапами реализации;
3. Другие (в окрУге) так еще не умели;
4. С НЕизменяемостью платформы (1С) пришлось согласиться, но конфигурация - не секретилась (не в моих правилах). Кто может сделать лучше - пожалуйста, никаких секретов;
5. Полученный карт-бланш позволил не спрашивать у сотрудников, а согласовывать этапы и реализацию с владельцем бизнеса. Его ослушаться не мог никто.
Вот я и подошел к СВОЕМУ видению процессов автоматизации.
1. Если владелец бизнеса знает, чего он хочет и МОЖЕТ свои желания реализовать - получится ВСЁ!!! Он найдет тех, кто сделают так, как он хочет.
......
Все остальные варианты - проще бросить монету "получится-не получится".
Вариант, когда исполнитель "вразумляет" владельца по поводу его (владельца) желаний - сродни гусарской рулетке. Хоть семи пядей во лбу, но это ИСПОЛНИТЕЛЬ. Не его это задача и не его дело.
Еще раз, спасибо, Юрий, за поднятую тему.
+130
  Участник сообщества      3608  
 - 10.04.10 21:34
Цитата
Евгений Кочуров пишет:
А как же быть с системами поддержки принятия решений и вообще всеми системами, которые нужны для руководителей, а не для исполнителей? Часто внедрение таких систем снижает производительность труда рядовых исполнителей. Как следствие - вызывают протест последних. Скажете, что не нужны такие системы?


Поскольку я ни разу в жизни не видел таких систем, могу только высказать своё мнение -- с большим риском сказать глупость.
Охотно им поделюсь, есл интересно (я же предупредил smile:).

Уверен только в одном -- эти системы можно разработать так, чтоб не снижать производительность труда рядовых исполнителей.

Цитата
Евгений Кочуров пишет:
Что касается ТЗ, то тут соглашусь с Анатолием: ТЗ на внедрение - очень полезная штука. ТЗ, фиксирующее детальные требование к ПО, редко когда имеет смысл, но тем не менее, иногда имеет! Например, когда интегрируются несколько систем и в разработке коннекторов задействованы несколько подрядчиков - Вы никуда не денетесь от ТЗ, фиксирующего спецификации API, без него подрядчики просто не смогут договориться.

Сколько ни внедрял -- всегда одно и то же. Начинается внедрение --- и "вдруг" выясняется множество важных нюансов, прямо противоречащих первоначальному представлению о работе программы. Закономерный итог планирования "для народа, но без народа". Хотя народ пытались привлекать -- делать тестовый месяц. Но народ не снисходил до тестирования. Надеялся -- авось обойдётся. Авось босс одумается.

Руокводители всё понимают, меня не винят -- но психовать начинают.

Кстати, из-за этого и ухожу из этой профессии -- уж очень нервные первые два месяца внедрения. Надоело.
  Участник сообщества  Михаил Байнов    271  
 - 10.04.10 22:14
Юрий, "если не собираетесь расширяться - автоматизация не нужна" - ложный посыл. Цель автоматизации, как сказали бы в советское время - "заменить людей машинами". Более подробно отпишусь через пару дней, спасибо что подняли тему.
  Участник сообщества      3608  
 - 11.04.10 9:07
Валерий Корчевский

У меня суббота-воскресенье -- преподавание, поэтому не получается дать развёрнутый ответ.

Поэтому пока напишу основную мысль, на основе которой буду строить свои ответы на Ваш пост.

Автоматизация -- это дорого и трудно.

Если собрать все расходы -- стоимость софта, гонорары, командировочные расходы, модернизация компьютерного парка, время высшегго руководства, потраченное на внедрение, потери от ошибок во время внедрения -- легко насчитаем 50 тыс. долларов США. А если сами пишем программу -- то и все 100.

При этом в первые месяцы внедрения улучшения работы, мягко скажем, не будет smile:)
Месяц дурдома можно гарантировать.

Поэтому нужны веские основания идти на это.

И я вижу одно: увеличение производительности труда.

А, скажем, с такими затратами и с такими муками приводить в порядок "топов", кторые "совсе от рук отбились" -- явная ошибка.

Рад, что Вы откликнулись на мой пост.
  Участник сообщества  Михаил Байнов    271  
 - 12.04.10 12:54
Цитата
Юрий Максименко пишет:
Правда заключается в том, что клиенты не знают, чего хотят

И это абсолютно нормально. Ведь клиенты редко имеют полное представление о возможностях предлагаемого продукта. Недавно делал небольшую табличку с макросами, основываясь на рисунке формата А3 (!). Сделал всё абсолютно не так, как там было нарисовано (потому что не увидел в рисунке необходимой мне логики), но всем понравилось! Сейчас, вероятно, перейду к ним на полный рабочий день и буду работать со своей демо-табличкой более предметно.

Цитата
Юрий Максименко пишет:
4. Софт должен быть изменяем

Да, как вариант. Но в большинстве случаев эффективнее заниматься поодержкой и модификацией системы кому? Правильно - самому разработчику.

Цитата
Юрий Максименко пишет:
5. Судьба внедрения -- в руках сотрудников

Вникнуть в административную структуру компании, в методы реального управления ей, обнаружить наиболее эффективные способы мотивации руководителей отделов, структурных подразделений - если эта проблема не решена на уровне компании - этим может заняться сторонний консультант. И это ещё одна составляющая успеха специалиста по внедрению.

Ещё одна интересная проблема - сроки внедрения. Я считаю, что консультанту, пришедшему со стороны, сроки внедрения предсказать невозможно. Даже топ-менеджмент может не владеть всей необходимой информацией для вычисления сроков внедрения системы автоматизации (здесь я имею в виду организации размером 50 и более рабочих мест для автоматизации). Оценить реальные сроки внедрения можно только "ввязавшись в бой", и продвижение к окончательному и бесповоротному внедрению системы может идти сколь угодно долго, в зависимости от многих факторов (технические ограничения, воля высшего руководства, интересы бизнеса).


Цитата
Юрий Максименко пишет:
Ухожу из этой профессии с выигрышным счётом 7:4 (есть шанс в лету изменить счёт на 8:3). Займусь менее нервными проектами.

Не будет ли рациональнее работать с каждой компанией последовательно, просто делая свою работу за фиксированную ставку. По завершении проекта переходить в другую организацию, но уже на более высокую ставку и с распухшим портфолио. Или не переходить, а расти внутри понравившейся организации.

Фриланс - это, как вы правильно заметили, весьма неспокойный и нервный режим работы, особенно когда сроки горят, а что делать непонятно...
  Участник сообщества      3608  
 - 12.04.10 13:24
Цитата
Михаил Байнов пишет:
Да, как вариант. Но в большинстве случаев эффективнее заниматься поодержкой и модификацией системы кому? Правильно - самому разработчику.

Конечно, если он хочет заниматься поддержкой и модификацией. А если нет?

Есть много причин, почему разработчик может отказаться от поддержки и модификации. В этом случае нужно не остаться у разбитого корыта.

Цитата
Михаил Байнов пишет:
Не будет ли рациональнее работать с каждой компанией последовательно, просто делая свою работу за фиксированную ставку.

А я так и работал -- поэтому счёт такой маленький (всего 11 очков за 10 лет). Кстати, и вот прямо сейчас так работаю.

Цитата
Михаил Байнов пишет:
Фриланс - это, как вы правильно заметили, весьма неспокойный и нервный режим работы, особенно когда сроки горят, а что делать непонятно...

Я говорю о том, что первые месяцы -- жуткий дурдом независимо от того, в каком качестве я осуществляю внедрение.
Истерики менеджеров. Истерики руководства. Авральный режим работы.

Я раньше верил, что это последний раз. Что следующий раз я избегну всего этого -- написав наконец программу, которая позволит мне этого избежать.

В этом году понял, что эта задача из той же серии, что и задача квадратуры круга или удвоения куба.

И сейчас занимаюсь не удвоением куба -- а удвоением доходов...
  Участник сообщества  Михаил Альперович    349  
 - 12.04.10 13:30
"....Я считаю, что консультанту, пришедшему со стороны, сроки внедрения предсказать невозможно..."

Зачем предсказывать? Предсказывают гадалки. Вы управляйтеsmile:)
Для того и занимаются взрослые дяди и тети с большими гонорарами проектным управлением, чтобы в проектные сроки и бюджеты достигать критериев завершенности проекта. Проект автоматизации - не исключение.

Любая работа занимает все отведенное для нее время - "Закон Мерфи"smile:)
+7
  Участник сообщества  Максим Беспалов    923  
 - 12.04.10 13:51
Добавлю свои пару копеек.
Мне представляется, чтоб говорить начистоту, нужно высказать реальное желание программиста (компании разработчика, внедренца) - далее "программист".
Постулат: Лекцию пишет лектор, студент сможет понеять насколько лектор был реально прав, только когда студент вырастет и будет знать сопоставимо много как тот лектор образца его студенчества.

Посему, два, точнее - три варианта:
1. Программист хочет много денег сразу, и потом не иметь головняка с заказчиком. Тогда - ТЗ как суть контракта, то, что надо сделать, протолкнуть, это товар за оговоренную сумму денег. Чем точнее ТЗ, тем программист более защищен от будущих проблем с "прозревшим" заказчиком.
Бизнес заказчика и степень адекватности ТЗ его реальной потребности в автоматизации, ИМХО, в своем пределе не имеют никакой взаимозависимости. Это - предмет договора, не более того.

2. Программист хочет небольшую денюжку но ежемесячно, фактически - он становится штатным работником, аутсорсером, партнером.

Тогда он делает то, что нужно, чтобы поддерживать желание владельца ему платить. Опять - к бизнесу собственника это имеет слабое отношение.

3. Программист хочет иметь, уже имеет, некое коробочное решение, которое он хочет продавать многим типовым заказчикам. Тогда ТЗ начинает приближаться к сути бизнеса, но этот вариант, как правило, является следствием работы многих лет по одному из первых двух.

Это ИМХО, но хотелось подчеркнуть - при чем тут заказчик? Говоря о заказчике, надо сначала показать свои цели. Три варианта, три разные стратегии, три разные пути работы с заказчиком. Это если честно говорить.
+1
  Участник сообщества      3608  
 - 12.04.10 14:10
Цитата
Максим Беспалов пишет:
1. Программист хочет много денег сразу, и потом не иметь головняка с заказчиком. Тогда - ТЗ как суть контракта, то, что надо сделать, протолкнуть, это товар за оговоренную сумму денег. Чем точнее ТЗ, тем программист более защищен от будущих проблем с "прозревшим" заказчиком.

Но в этом случае он не защищён от потери репутации.

Никто ведь не согласится с тем, что "операция прошла успешно, но больной умер".

Поэтому выигрыш в крючкотворстве, на мой взгляд, хуже проигрыша.

Цитата
Максим Беспалов пишет:
2. Программист хочет небольшую денюжку но ежемесячно, фактически - он становится штатным работником, аутсорсером, партнером.

Единственный жизнеспособный вариант сотрудничества программиста и фирмы-заказчика.

Получится или нет внедрение -- сказать нельзя, но шанс появляется.

Цитата
Максим Беспалов пишет:
3. Программист хочет иметь, уже имеет, некое коробочное решение, которое он хочет продавать многим типовым заказчикам. Тогда ТЗ начинает приближаться к сути бизнеса, но этот вариант, как правило, является следствием работы многих лет по одному из первых двух.


Увы -- это утопия. Моя несбывшаяся мечта.
  Участник сообщества  Максим Беспалов    923  
 - 12.04.10 14:20
Цитата
Юрий Максименко пишет:
Но в этом случае он не защищён от потери репутации.

Никто ведь не согласится с тем, что "операция прошла успешно, но больной умер".

Поэтому выигрыш в крючкотворстве, на мой взгляд, хуже проигрыша.


Не совсем так. Я не верю в репутацию как реальное "мотто" программиста. Причем заметье - я называю "программист" как бизнес-юнит, функцию, а не персону. И кто видел программиста, потреявшего рынок и ушедшего в пастухи по причине потери репутации? Больной не умрет, причем не умрет никогда, потому что на данной стадии не затрагиваются его жизненно- важные органы. Примеров тому - легион.
+1
  Участник сообщества      3608  
 - 12.04.10 14:27
Цитата
Максим Беспалов пишет:
Я не верю в репутацию как реальное "мотто" программиста. Причем заметье - я называю "программист" как бизнес-юнит, функцию, а не персону. И кто видел программиста, потреявшего рынок и ушедшего в пастухи по причине потери репутации?

В пастухи-не в пастухи, а потеряло бизнес много контор-разработчиков софта. Ещё больше -- так и не приобрели его.
Цитата
Максим Беспалов пишет:
Больной не умрет, причем не умрет никогда, потому что на данной стадии не затрагиваются его жизненно- важные органы. Примеров тому - легион.

Обидно потерять деньги и время -- и в итоге не автоматизироваться.

Каждый такой случай -- пятно на репутации.
  Участник сообщества  Максим Беспалов    923  
 - 12.04.10 14:33
Цитата
Юрий Максименко пишет:
Обидно потерять деньги и время -- и в итоге не автоматизироваться.

Каждый такой случай -- пятно на репутации.


Теоретически - да, а практически... у нас нет публичного рейтинга программистов, это все слухи, личные впечатления. Насколько говорящий знал суть происходящего в проекте, что он может сказать? кому он это может сказать? Кто будет спрашивать насчет репутации будущего портнера, у кого он будет спрашивать, где он найдет информацию - слишком много неопределенности в практической стороне понятия "репутация"....
+1
  Участник сообщества      3608  
 - 12.04.10 14:40
Цитата
Максим Беспалов пишет:
Теоретически - да, а практически... у нас нет публичного рейтинга программистов, это все слухи, личные впечатления. Насколько говорящий знал суть происходящего в проекте, что он может сказать? кому он это может сказать? Кто будет спрашивать насчет репутации будущего портнера, у кого он будет спрашивать, где он найдет информацию - слишком много неопределенности в практической стороне понятия "репутация"....

Скажу про отрасль, которую, не побоюсь этого слова, знаю. Туризм.

Поскольку в нём много строится на личных договорённостях -- все всех знают. И знают, кто как автоматизировался.
И некоторый рейтинг, хоть и не публичный, существует.

У меня есть страница, на которой я собирал сведения о софте для туризма -- всё время приходится убирать оттуда "выбывшие из забега" программы.
  Участник сообщества  Максим Беспалов    923  
 - 12.04.10 15:01
Цитата
Юрий Максименко пишет:
У меня есть страница, на которой я собирал сведения о софте для туризма -- всё время приходится убирать оттуда "выбывшие из забега" программы.


Вот-вот, Вы пытались собрать некое подобие базиса для рейтинга. Я знаю немного про туризм, смежная отрасль smile:D
+1
  Участник сообщества  Михаил Байнов    271  
 - 12.04.10 15:25
Цитата
Юрий Максименко пишет:
И некоторый рейтинг, хоть и не публичный, существует.

Суть не в рейтинге, а в "рекомендациях лучших собаководов". Если они есть - дело пойдёт...
И насколько я понимаю, речь идет не о мегаполисе, а о достаточно небольшом региональном рынке. Там действительно могут иметь место неофициальные рейтинги. Вообще, при грамотной постановке бизнеса - заводить себе ещё второго человека - специалиста по PR, чтобы ослеживал и адекватно ("асимметрично") реагировал на нехорошие отзывы в Интернете.
  Участник сообщества  Максим Беспалов    923  
 - 12.04.10 15:45
Цитата
Михаил Байнов пишет:
И насколько я понимаю, речь идет не о мегаполисе, а о достаточно небольшом региональном рынке. Там действительно могут иметь место неофициальные рейтинги. Вообще, при грамотной постановке бизнеса - заводить себе ещё второго человека - специалиста по PR, чтобы ослеживал и адекватно ("асимметрично") реагировал на нехорошие отзывы в Интернете.


Вы сами себе противоречите. На небольшом региональном рынке работает только вариант номер 2 - доить пока доится. И все делается по знакомству и рекомендации "собаковода" - это да, но там нафиг не нужен специальный PR человек, клиента лижем во все места пока не зарастет. А там, где нужен PR человек - там не работают собаководы, бо - рынок слишком велик для опоры на личности.
+1
  Эксперт  Валерий Корчевский    1653  
 - 12.04.10 16:14
Я рассматриваю этот рынок для себя несколько иначе.
Я ОТЛИЧНО знаю производство, как предметную область автоматизации. С некоторой (подозреваю, что большой) долей самонадеянности я уверен, что перед владельцем производственного бизнеса ДОЛЖНЫ встать определенные вопросы. Именно совершенствованию своих знаний и навыков в решении самых разных "модификаций" этих вопросов я и посвящаю свое время. Для меня не важно, КТО сегодня этим озаботился. Важно то, что в границах квартала хоть кто-то из владельцев производственного бизнеса озаботится своими проблемами и предпримет ПОПЫТКУ их решения. Это и станет так называемым "основным аэродромом". Квалифицированное объяснение своей роли и места в процессе автоматизации приводит к согласию на неполный рабочий день. Таким образом можно поддерживать "запасные аэродромы", которые ВЫНУЖДАЮТ не зацикливаться на однобоком развитии, а поспевать "по всему фронту". Кто знает, тот подтвердит, что график работы достаточно неровный, бывают сутки (и не одни) без отдыха. Но ... такова сегодня цена независимости от настроений работодателя.
+130
  Участник сообщества      3608  
 - 12.04.10 16:17
Цитата
Михаил Байнов пишет:
И насколько я понимаю, речь идет не о мегаполисе, а о достаточно небольшом региональном рынке.

Называйте Москву как хотите smile:)
  Участник сообщества  Максим Беспалов    923  
 - 12.04.10 16:36
Цитата
Валерий Корчевский пишет:
Важно то, что в границах квартала хоть кто-то из владельцев производственного бизнеса озаботится своими проблемами и предпримет ПОПЫТКУ их решения. Это и станет так называемым "основным аэродромом".


Весьма значимый посыл. Начало "коробочного" отношения к проблематике. Я не буду автоматизировать бардак по заказу, но буду для технологического процесса, где я специалист. ИМХО - редкий по своей здравости подход.
+1
  Участник сообщества  Михаил Байнов    271  
 - 12.04.10 16:36
Цитата
Максим Беспалов пишет:
там нафиг не нужен специальный PR человек

Согласен.


Цитата
Валерий Корчевский пишет:
Квалифицированное объяснение своей роли и места в процессе автоматизации приводит к согласию на неполный рабочий день.


Там, в далекой холодной Москве, дядьки в тулупах работают (по твоим регламентам), а ты ... наяриеваешь мясо ягнёнка с матоке и пучком салата, запивая кока-колой из стеклянной бутылочки. А за окном закат, сверчки, и только изредка пролетит редкая птица марабу...
  Эксперт  Валерий Корчевский    1653  
 - 12.04.10 17:08
Цитата
Михаил Байнов пишет:
Там, в далекой холодной Москве, дядьки в тулупах работают (по твоим регламентам), а ты ... наяриеваешь мясо ягнёнка с матоке и пучком салата, запивая кока-колой из стеклянной бутылочки. А за окном закат, сверчки, и только изредка пролетит редкая птица марабу...

В далекой холодной Москве в тулупах работают дядьки, которые мне не знакомы. Те, которые мне знакомы - тулупов не надевают лет 30 как.
Мясо ягненка никто так и не смог нормально приготовить (из ближайшего окружения), поэтому предпочитаю старый добрый стейк (так называется нога (задняя) поросенка, "замаринованная" в мёде и зажаренная в духовке). И было это 1 января, а сейчас - моя смерть от обильного слюноотделения будет на твоей совести. Окон - нет, сверчки - в прошлом году ушли. Проводки, почему-то, после доработки конфигурации не формируются. Закат будет без меня. smile:(
+130


Только участники сообщества могут обсуждать статьи
Читают тему гостей: 1, пользователей: 0, из них скрытых: 0



soc
6