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

Внимание: речь исключительно про мой опыт! Допускаю, что в разработке, к примеру, под мобильные приложения, а не под web, все может быть совершенно иначе. 😉 

Итак, гоните в шею если кто-то говорит вам:

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

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

Еще заявка нужна чтобы не потерялось если сделать сейчас нельзя. Она нужна если внести нужно спорные изменения которые должны быть обсуждены. 

Приведу пример во что обычная жизнь превращается с заявками.

Задача: Сходить в туалет. Не пописать. 🙂 

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

И ты снова идешь к Маше и спрашиваешь про туалетную бумагу. Цепочка повторяется, но в других лицах т.к. мастер туалетной бумаги в компании Алексей, а не Вася. И вот ты с бумагой в туалете. Злой. Идешь к Олегу, который все это придумал. А он тебе отвечает: так ты в первой заявке написал просто, что тебе в туалет. Но ты не написал, что тебе "не пописать". Написал бы — тогда бы тебе конечно сразу и про бумагу сказали. 

Занавес. 

Лишнее ненужное звено, которое или автоматизируется готовыми средствами довольно просто или же просто отсутствует в процессе. Человек не хочет заниматься реальными вещами — разработкой feature, но хочет быть важным, незаменимым звеном цепочки.

Я всегда старался избегать этой обязанности. Когда мы от разработки в общей ветке, где это было не нужно, перешли к разработке в отдельных ветках, то переложили pull request на статусы с Jira. Если QA проверил задачу и передвинул в следующий статус, то это автоматический approve pull request в соответствующую ветку: staging, master. В ветку develop approve pull request проходит после командного code review и проверки задачи соответствие code style, прогонку тестов в Team City тоже через изменение статуса в Jira. 

При наличии в master только проверенных задач сборку релиза можно или вообще делать автоматической по появлению каждой задачи с выкладкой или разрешать максимальному количеству людей, а как минимум: всем членам команды от младшего тестировщика до руководителя департамента и product owner. Выкладывает тот, кто больше всего хочет эту задачу увидеть как можно раньше. В идеале это, конечно, разработчик который взялся за эту задачу.

Путь задачи от постановки до production должен быть максимально быстрым и коротким. Добавление нового статуса очевидно удлиняет этот путь, конечно если речь не про состояние, которое задача проходит автоматически. Человек просто формалист и соблюдение неких "ритуалов" и условностей для него важнее настоящей цели — готовая и работающая feature на production.

…

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

Настоящему лидеру в настоящей команде не нужна взаимозаменяемость (мы же понимаем, что что наличие двух рук у человека не совсем означает их взаимозаменяемость?). Он отлично знает плюсы каждого своего человека. Он знает и понимает что без Димы в проекте будет одно, без Тани другое, без Вадима третье, без Артема вообще труба и т.д. Что реально заменить их нельзя, да и не нужно т.к. он — настоящий руководитель и лидер и эти люди от него не уйдут. Если уйдут, то предупредят настолько заранее насколько это возможно. А форс-мажор — не аргумент. Мы не живем каждый час своей жизни с мыслями о кирпиче на голову. 

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

Куда же без рекурсии. 😉 Если кто-то говорит вам что вы должны делать — не стоит этому слепо следовать. 

… продолжение следует.