Ученые установили, что за ограду с табличкой «Не входить! Велосипеды не пристегивать!» все равно входят 27% желающих срезать путь, но если рядом пристегнуть велосипед, число вырастет до 82%.
Это частный случай поведения, описаного в 1982 Джеймсом Вилсоном и Джорджем Киллингом в статье «Разбитое окно». Дело в том, что человек гораздо чаще нарушает установленые нормы, если видит, что до него их кто то уже нарушил. Если во дворе появятся испачканые стены, неубранный мусор, или разбитое окно, к ним как магнитом притянутся пьяные компании, брошенные автомобили, гоп-стоперы и так далее. Чтобы избежать этого, надо душить в зародыше мелкие нарушения.
Мне довелось поработать над довольно крупным проектом, у которого сильно хромало качество кода. Не было внутренних стандартов, очень различался уровень исполнителей. Трясина всеобщей апатии засосала меня довольно быстро, и я поплыл по течению, ляпая код абы как и насаждая новые баги во время фикса старых. Сроки в компании срывались постоянно, ни один майлстоун вовремя не сдавался.
Через некоторое время произошли кадровые перестановки, и под моим началом оказалась группа из пяти таких же апатичных программистов. Мне был очерчен фронт работ, и болото передо мной заиграло новыми оттенками уныния, ибо лиды регулярно получали по башке за срыв сроков. Но к счастью именно тогда один коллега рассказал мне про данную теорию. И вот какие выводы я из нее сделал:
Апатичным программистам это не сильно понравилось. Некоторые задачи заворачивались по два-три раза.
Некоторых пришлось уволить, (к счастью, у меня были такие полномочия), и набрать новых. Рефакторинг старого болота длился около года, иногда постепенно, иногда полным переписыванием части функционала с нуля (очень хорошо подумайте, прежде чем делать это!). В результате получился архитектурно стройный модуль, с четким, понятным интерфейсом, и понятной реализацией. Уровень программирования в отделе вырос, люди научились не делать грубых ошибок.
На уровне отдела данный подход сработал замечательно. К сожалению, другие отделы продолжили работать по старой схеме. «Чудачества» по поводу ревью их изменений в нашем коде они терпели, но сами они предпочли работать по старинке. Поиск багов в их коде очень сильно расхолаживал и каждый срыв майлстоуна теперь уже воспринимался не как обыденность, а «мы все сделали, а из-за них опять фейл». В общем, через пару лет, я сменил работу, так и не сумев насадить культуру во всей компании, что грустно. Но тем не менее надеюсь, что мой опыт поможет другим выживать в подобных компаниях и даже менять их к лучшему :)
UPD: статья про эксперименты с «Теорией Разбитого Окна»
UPD 2: Иллюстрация от cruel_clown и Liksys
Что же это, доктор?
Это частный случай поведения, описаного в 1982 Джеймсом Вилсоном и Джорджем Киллингом в статье «Разбитое окно». Дело в том, что человек гораздо чаще нарушает установленые нормы, если видит, что до него их кто то уже нарушил. Если во дворе появятся испачканые стены, неубранный мусор, или разбитое окно, к ним как магнитом притянутся пьяные компании, брошенные автомобили, гоп-стоперы и так далее. Чтобы избежать этого, надо душить в зародыше мелкие нарушения.
Как это относится к IT?
Мне довелось поработать над довольно крупным проектом, у которого сильно хромало качество кода. Не было внутренних стандартов, очень различался уровень исполнителей. Трясина всеобщей апатии засосала меня довольно быстро, и я поплыл по течению, ляпая код абы как и насаждая новые баги во время фикса старых. Сроки в компании срывались постоянно, ни один майлстоун вовремя не сдавался.
Через некоторое время произошли кадровые перестановки, и под моим началом оказалась группа из пяти таких же апатичных программистов. Мне был очерчен фронт работ, и болото передо мной заиграло новыми оттенками уныния, ибо лиды регулярно получали по башке за срыв сроков. Но к счастью именно тогда один коллега рассказал мне про данную теорию. И вот какие выводы я из нее сделал:
- Разработка моего отдела была выделена в отдельный модуль.
- Вся работа с остальным продуктом была направлена через регламентированные интерфейсы.
- В отделе был введен жесткий код-стандарт.
- Все задачи начали проходить обязательное код-ревью.
- Все изменения от других отделов обязательно контролировались и ревьюились.
Апатичным программистам это не сильно понравилось. Некоторые задачи заворачивались по два-три раза.
Некоторых пришлось уволить, (к счастью, у меня были такие полномочия), и набрать новых. Рефакторинг старого болота длился около года, иногда постепенно, иногда полным переписыванием части функционала с нуля (очень хорошо подумайте, прежде чем делать это!). В результате получился архитектурно стройный модуль, с четким, понятным интерфейсом, и понятной реализацией. Уровень программирования в отделе вырос, люди научились не делать грубых ошибок.
Но не все так сказочно.
На уровне отдела данный подход сработал замечательно. К сожалению, другие отделы продолжили работать по старой схеме. «Чудачества» по поводу ревью их изменений в нашем коде они терпели, но сами они предпочли работать по старинке. Поиск багов в их коде очень сильно расхолаживал и каждый срыв майлстоуна теперь уже воспринимался не как обыденность, а «мы все сделали, а из-за них опять фейл». В общем, через пару лет, я сменил работу, так и не сумев насадить культуру во всей компании, что грустно. Но тем не менее надеюсь, что мой опыт поможет другим выживать в подобных компаниях и даже менять их к лучшему :)
UPD: статья про эксперименты с «Теорией Разбитого Окна»
UPD 2: Иллюстрация от cruel_clown и Liksys
