Если честно, не припомню такого, чтобы программисты сами по своей инициативе взяли и сделали что-то совсем плохое. Обычно этим людям есть чем заняться, просто так от скуки они портить ничего не будут. Максимум из любопытства — попробовать что-то новое, проверить, что будет если сделать вот так или так, — но для любопытства всегда есть тестовое приложение или приложение разработки.
Кодревью — это основной механизм борьбы с «беспределом».
Второй механизм — нанимать опытных разработчиков, которые поработали в конторах с хорошей программистской дисциплиной. Меня радует ошарашенный вид наших разработчиков, когда программист заказчика говорит про свой хардкод: «Ну мы всегда делаем так!» — это воспринимается ими как преступление, как что-то противоестественное. Такие ребята, скорее всего, не будут делать откровенную «грязь» в коде, даже работая у клиента. Ну по крайней мере, первые несколько лет)))
Все остальные рекомендации — это то же ревью кода, но в другой форме: периодический внешний аудит кода, опытный менеджер-непрограммист и т.п.
Ситуация: внедрили ERP-систему. Потратили на это нелегкое дело много денег, все более или менее работает, дальше надо сопровождать, делать небольшие изменения. Изменений не очень много, денег жалко. Поэтому берут одного программиста в штат и тот выполняет все функции: и аналитик, и программист, и архитектор, и админ.
Да, это неправильно. Да, это может привести к плохим последствиям.
Но это не такая уж редкость.
— вот это как раз про такой вопрос.
Но если после таких вопросов пользователь понимает, что он не прав, но имеет возможность продавить программиста на реализацию этого решения, то толка особого в вопросах нет.
«Беспредел» есть и по ту, и по эту сторону баррикад. Просто причины этих беспределов разные. Вполне возможно, что я предвзято смотрю на этот вопрос — по ту сторону баррикад я не был, хотя и много общался с программистами клиента.
К программистам особых претензий нет: я понимаю, что разные ситуации бывают.
Тут больше о том, как создавать условия, в которых программисты не будут вынуждены делать странные вещи.
у продукта должны быть хозяин (контролирует и несет ответственность), аналитик (умеет разговаривать с Алевтиной Светозаровной на ее языке) и архитектор (видит всю картину и принимает решения как ее менять, чтобы было единообразно и эффективно) — это точки входа.
Полностью с вами согласен. То, что вы описали, — идеальный вариант. Но держать столько IT специалистов, тем более довольно дорогих и квалифицированных, — не каждое предприятие такое потянет. Я видел предприятия, где ERP сопровождали 1-2 разработчика, это довольно рапространенное явление.
В условиях ограниченного бюджета каждый программист вынужден с Алевтиной Светозаровной общий язык находить, а самый опытный из разрабов выполняет роль архитектора. Вот с хозяином продукта, конечно, сложнее…
Так к Алевтине Светозаровне претензий нет)) Претензии к тем, кто её использует в качестве символа. С умнейшими действительно стоит договариваться — без них никак.
А «беспощадно, люто, везде и всегда» — это только против лени и отсутствия дисциплины.
В этом мы не отличаемся — уверен, при внедрении любой ERP-системы проводят этап концептуального планирования сильно раньше начала опытной эксплуатации. Как я и писал к началу опытной все модификации реализованы, все прекрасно понимают, где изменена система, а где бизнес-процессы будут работать по-другому, есть написанные дизайны или СТП, инструкции, правила кодирования и т.д.:
в процессе опытной эксплуатации, когда уже все бизнес-процессы в новой системе описаны, роли настроены, модификации сделаны, инструкции выданы и надо просто начинать работать.
Проблема не в отсутствии этого этапа. Проблема в том, что на этапе опытной эксплуатации начинаются попытки переиграть те согласованные и закрепленные в регламентах решения, которые были приняты при концептуальном планировании.
Как я уже писал, современные ERP-системы имеют избыточный функционал, — чаще возникает вопрос, каким из нескольких способов лучше реализовать то, что хочет заказчик. И большинство сложных процессов можно реализовать в системе путем настроек.
Проблемы, к сожалению, возникают не со сложными процессами, а со всякими «рюшечками», «мне так неудобно», желанием сохранить старые отчеты, для которых в новой системе есть аналоги, нежеланием вести в системе весь нужный объем информации и поддерживать данные актуальными.
Анализ проблемы проводился, просто заметка была не об этом) В рамках примера я посчитал достаточной формулировку «все тормозит»)
Скорее всего, новые внедренцы при оценке ситуации напирают на негативные моменты «убили систему, все тормозит», так как им это выгодно, чтобы продать проект заново, как новую машину, вместо старой с засорившейся пепельницей.
Вы же сказали, что перевнедрение — это адское количество организационных моментов. Да, бюджет на внедрение новой системы, скорее всего, будет больше бюджета на сопровождение старой. Но и проблем и репутационных рисков будет существенно больше — по моему опыту, если существующую систему можно просто поддерживать, то интегратор тоже не сильно заинтересован в новом внедрении, можно спокойно совершенствовать то, что есть.
Но вот вердикт «убили систему — все тормозило — пришлось заново внедрять» отдает дилетантством.
Согласен, решение спорное. Но там при перевнедрении менялась версия системы, добавлялся новый функционал, который был действительно нужен заказчику. К тому же такие решения никогда не принимаются по одной простой технической причине («все тормозит — давайте разрушим старое и построим новое»), есть и организационные, и политические моменты.
В этом кейсе важен не факт перевнедрения (такая радикальная мера — скорее исключение), а мысль, что свой штат разработчиков при неаккуратном подходе может создать проблемы бизнесу.
Кодревью — это основной механизм борьбы с «беспределом».
Второй механизм — нанимать опытных разработчиков, которые поработали в конторах с хорошей программистской дисциплиной. Меня радует ошарашенный вид наших разработчиков, когда программист заказчика говорит про свой хардкод: «Ну мы всегда делаем так!» — это воспринимается ими как преступление, как что-то противоестественное. Такие ребята, скорее всего, не будут делать откровенную «грязь» в коде, даже работая у клиента. Ну по крайней мере, первые несколько лет)))
Все остальные рекомендации — это то же ревью кода, но в другой форме: периодический внешний аудит кода, опытный менеджер-непрограммист и т.п.
Да и уходят люди. Ключевые пользователи, обученные при внедрении аналитики — сегодня они работают, а завтра могут уже не работать.
Да, это неправильно. Да, это может привести к плохим последствиям.
Но это не такая уж редкость.
А чем вы сейчас занимаетесь? Пригодился опыт, полученный тогда при разработке ERP, в дальнейшей работе?
— вот это как раз про такой вопрос.
Но если после таких вопросов пользователь понимает, что он не прав, но имеет возможность продавить программиста на реализацию этого решения, то толка особого в вопросах нет.
Тут больше о том, как создавать условия, в которых программисты не будут вынуждены делать странные вещи.
Полностью с вами согласен. То, что вы описали, — идеальный вариант. Но держать столько IT специалистов, тем более довольно дорогих и квалифицированных, — не каждое предприятие такое потянет. Я видел предприятия, где ERP сопровождали 1-2 разработчика, это довольно рапространенное явление.
В условиях ограниченного бюджета каждый программист вынужден с Алевтиной Светозаровной общий язык находить, а самый опытный из разрабов выполняет роль архитектора. Вот с хозяином продукта, конечно, сложнее…
А «беспощадно, люто, везде и всегда» — это только против лени и отсутствия дисциплины.
Проблема не в отсутствии этого этапа. Проблема в том, что на этапе опытной эксплуатации начинаются попытки переиграть те согласованные и закрепленные в регламентах решения, которые были приняты при концептуальном планировании.
Проблемы, к сожалению, возникают не со сложными процессами, а со всякими «рюшечками», «мне так неудобно», желанием сохранить старые отчеты, для которых в новой системе есть аналоги, нежеланием вести в системе весь нужный объем информации и поддерживать данные актуальными.
Вы же сказали, что перевнедрение — это адское количество организационных моментов. Да, бюджет на внедрение новой системы, скорее всего, будет больше бюджета на сопровождение старой. Но и проблем и репутационных рисков будет существенно больше — по моему опыту, если существующую систему можно просто поддерживать, то интегратор тоже не сильно заинтересован в новом внедрении, можно спокойно совершенствовать то, что есть.
Согласен, решение спорное. Но там при перевнедрении менялась версия системы, добавлялся новый функционал, который был действительно нужен заказчику. К тому же такие решения никогда не принимаются по одной простой технической причине («все тормозит — давайте разрушим старое и построим новое»), есть и организационные, и политические моменты.
В этом кейсе важен не факт перевнедрения (такая радикальная мера — скорее исключение), а мысль, что свой штат разработчиков при неаккуратном подходе может создать проблемы бизнесу.