Comments 14
Ну, историю изменений понятно, зачем хранить. Особенно говнокода. Когда лет через пять-десять возникнет вопрос, а что за говно эта говнострочка делает — тут без истории изменений не разобраться.
Даже в нормальном коде полезно, в читабельном, чистом, с комментариями и тестами.
Когда соревнуются маркетологи, инженеры отдыхают. А там либо шах, либо ишак - без разницы - деньги уже проедены. С учётом что даже на стороне заказчика куда важнее отчитаться об истории успеха нежели иметь её по факту, очень непохоже что что-то изменится ближайшие двадцать лет.
Проблема системная и она обычно в головах, а не в компьютерах. Подобные вопросы - отдельный рынок консалтинговых услуг. И рынок этот только растёт. До тех пор пока:
заказывают одни, а работают другие (большие боссы пишут требования от лица пользователя для системы и процесса, в котором они не работали)
платят за красиво (вот деньги и сделайте мне хорошо, я сам не хочу это понимать)
от разработчиков ожидают внедрения (вот вы систему сделали, теперь сделайте чтоб все ей пользовались)
сделай новое по старому (like for like легаси системы, подражание оффлайновым процессам)
мы платим - вы танцуете (нам всё равно какие бизнес и технические проблемы - клиент всегда прав, так что делайте облако на моём заводе и чтоб ключ от сервера был у меня)
левая голова не знает что делает правая (начальники отделов ведут конкурирующую или параллельную политику)
То цирк будет продолжаться. Потому как система - инструмент и не более. Вместо молотка всем выдали шуроповёрт и всё те же гвозди - прироста производительности или уменьшения усталости работника ждать не стоит.
Принцип я понял.
Осталось реализовать...
Где деньги, Зин?)
Касательно git - дело не столько в самой системе, сколько в возможностях EDT (пусть и сырой донельзя).
Касательно мобильного приложения - все же зависит от его назначения. Нам удалось с помощью мобильного приложения (и некоторой дополнительной обвязки) уменьшить количество складских работников вдвое.
У нас любимый вопрос: На бумаге отчёты можно будет не писать\печатать? Ну и следующий, а как нам подписывать электронные отчёты, чтобы на бумаге не писать? Причём при этом люди не электронную подпись имеют в виду, а закорючку.
В тексте вижу пренебрежение к CRM, оно какбе противопоставляется 1С, хотя учетная система и CRM друг друга дополняют: 1С констатирует продажу, как правило, около 10%, а CRM объясняет, почему не состоялись остальные 90% и что с этим делать. К сожалению, модуль CRM в любой конфе 1C выглядит достаточно плачевно, чтобы им пользоваться.
Планирование - штука сама по себе сложная.
Никто со 100% гарантией не скажет, что будет завтра. Наверное поэтому системы планирования так и не приживаются, и даже на той же 1С ничего путевого нет до сих пор, при всём немалом потенциале платформы и количестве разработчиков.
Зачем вам писать AS IS, это только лишние расходы, вот, почитайте, как БУДЕТ™
В автоматизации тестирования тоже есть нюансы. Иногда думают что автотесты повысят качество продукта. Но автотесты это только инструмент для выявления ошибок, качество повышают программисты когда ошибки устраняют. А когда ты ждешь по шесть месяцев чтобы найденные баги пофиксили, то получается как в небезызвестной цитате "Если автоматизировать хаос, получится автоматизированный хаос". Т.е. автоматизация накидывает еще больше ошибок на конвеер, в то время как ожидают, что ошибок станет меньше. Потому что нужно ошибки найденые автоматизацией решать в самую первую очередь, а не складывать их в общий багтрекер. А когда автоматизацию заказывают "как-сервис", то получается порой наоборот - найденные ошибки копят в багтрекере, пишут солидные отчеты и таскают по всем нужным и ненужным совещаниям, чтобы было видно за что деньги плачены.
Контрольный в голову. О чём нельзя спрашивать после автоматизации