Контрольный в голову. О чём нельзя спрашивать после автоматизации

Ну, историю изменений понятно, зачем хранить. Особенно говнокода. Когда лет через пять-десять возникнет вопрос, а что за говно эта говнострочка делает — тут без истории изменений не разобраться.

Даже в нормальном коде полезно, в читабельном, чистом, с комментариями и тестами.

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

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

• заказывают одни, а работают другие (большие боссы пишут требования от лица пользователя для системы и процесса, в котором они не работали)

• платят за красиво (вот деньги и сделайте мне хорошо, я сам не хочу это понимать)

• от разработчиков ожидают внедрения (вот вы систему сделали, теперь сделайте чтоб все ей пользовались)

• сделай новое по старому (like for like легаси системы, подражание оффлайновым процессам)

• мы платим - вы танцуете (нам всё равно какие бизнес и технические проблемы - клиент всегда прав, так что делайте облако на моём заводе и чтоб ключ от сервера был у меня)

• левая голова не знает что делает правая (начальники отделов ведут конкурирующую или параллельную политику)

То цирк будет продолжаться. Потому как система - инструмент и не более. Вместо молотка всем выдали шуроповёрт и всё те же гвозди - прироста производительности или уменьшения усталости работника ждать не стоит.

Принцип я понял.

Осталось реализовать...

Где деньги, Зин?)

Касательно git - дело не столько в самой системе, сколько в возможностях EDT (пусть и сырой донельзя).

Касательно мобильного приложения - все же зависит от его назначения. Нам удалось с помощью мобильного приложения (и некоторой дополнительной обвязки) уменьшить количество складских работников вдвое.

У нас любимый вопрос: На бумаге отчёты можно будет не писать\печатать? Ну и следующий, а как нам подписывать электронные отчёты, чтобы на бумаге не писать? Причём при этом люди не электронную подпись имеют в виду, а закорючку.

В тексте вижу пренебрежение к CRM, оно какбе противопоставляется 1С, хотя учетная система и CRM друг друга дополняют: 1С констатирует продажу, как правило, около 10%, а CRM объясняет, почему не состоялись остальные 90% и что с этим делать. К сожалению, модуль CRM в любой конфе 1C выглядит достаточно плачевно, чтобы им пользоваться.

Планирование - штука сама по себе сложная.

Никто со 100% гарантией не скажет, что будет завтра. Наверное поэтому системы планирования так и не приживаются, и даже на той же 1С ничего путевого нет до сих пор, при всём немалом потенциале платформы и количестве разработчиков.

Зачем вам писать AS IS, это только лишние расходы, вот, почитайте, как БУДЕТ™

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