Чужая статья. Особенности русской разработки

http://habrahabr.ru/company/scrumtrek/blog/185334/
Процитирую немного:

Все идет с раннего детства. Так нас воспитывали. И не только двор и школьные приятели. Когда мой старший сын ходил в детский садик, я своими ушами слышал, как воспитательница внушала рыдающему ребенку, который жаловался на толкнувшего его товарища, что ябедничать нехорошо. 

----

Это тоже часть нашей с вами культуры, обратная сторона нежелания эскалировать проблемы. Мы привыкли давать обратную связь своему товарищу намного более открыто и прямо. Мы не так сильно стесняемся конфликтовать, как наши западные коллеги.  

----

Наши доверяют людям, доказавшим свое превосходство. И реальные лидеры привыкают принимать решения самостоятельно и никогда не встречают сопротивления. 

----

Такое общение называется low context. Мы даем мало контекста. Апофеозом для меня было когда-то имейл от админа с одним словом «Да». Что да? Оказывается, я у него спросил что-то в коридоре и он обещал посмотреть. 

P.S. от себя добавлю одну неосторожную вещь, о которой не пишет автор - если у кого-то есть "вопросы" к работе своего менеджера (неважно какого уровня) - это по-русски означает - "стучать". Это - правда. И главное - ДРУГИЕ менеджеры так это и воспримут. И будут правы. На нашей почве.

P.P.S. Завидую людям, которые не "боятся" писать подобные статьи. Ибо это тоже означает "стучать". На нашей почве.

P.P.P.S. В России - только в маленьких конторах есть возможность ощущать "драйв" и "сопричастность". На нашей почве.

P.P.P.P.S. "резать правду матку" и "отгораживаться стеной" - можно с одним и тем же человеком. Вопрос - какую "роль" он в данный момент исполняет. На нашей почве.

Новый коллега тут долго и мучительно искал ошибку в МОЁМ коде

"Новый" коллега тут долго и мучительно искал ошибку в МОЁМ коде. И в итоге - НАШЁЛ. Меня к этому процессу особо не привлекали - ну такое по-моему бывает везде - "мол конечно ты за 5 мин найдёшь, но с одной стороны - у тебя своих задач хватает, а с другой стороны - "пусть парень поиузучает"". А если что мол - "проконсультируешь". Что ХАРАКТЕРНО - "парень" - долго ВДУМЧИВО "курил" исходники, а потом написал мне комментарий, что "мол так и так, проблема в этом". И (как я сейчас понимаю) - комментарий был КРАЙНЕ вдумчив и КОРРЕКТЕН, и при этом описывал проблему ПРАКТИЧЕСКИ ПОЛНОСТЬЮ. Но мне что называется "было недосуг" и я "находился в плену собственных стереотипов" - ГДЕ БЫ эта ошибка могла бы быть. И я направил коллегу по ЛОЖНОМУ следу. Я вывалил на него МАССУ "полезной", но в принципе - НЕ ОТНОСЯЩЕЙСЯ к делу информации. Что мол - "я бы копал бы там-то и там-то". Что характерно - никакой "стены отчуждения", или нежелания помочь - не было. Мы потом не раз эту проблему обсуждали устно в курилке. С интересом. И всё дальше и дальше я направлял коллегу по ЛОЖНОМУ ПУТИ.

Потом - "СЛУЧИЛОСЬ ЧУДО". Мы вернулись на новый виток. Коллега был вдумчив и упорен. И на НОВОМ ВИТКЕ он мне написал СВОЙ ПЕРВЫЙ КОММЕНТАРИЙ. Ну СЛОВО В СЛОВО. Я его прочитал ВНИМАТЕЛЬНО и сказал - "ну вот же в чём проблема"! "Чего ж" ты мол раньше молчал! Вот "в этом" и "этом". И проблема - решилась.

Я правда потом (случайно) - перечитал самый ПЕРВЫЙ комментарий. И осознал, что там написано - РОВНО ТО ЖЕ САМОЕ. Что и в том комментарии, который РЕШИЛ проблему.

Мне стало даже "стыдно". За то что, что попусту потратил чужое время.

Я даже сказал коллеге об этом. Правда услышал в ответ - "зато я столько интересного узнал". И это кстати - правда. Может быть это конечно и к лучшему. Но к ДАННОЙ КОНКРЕТНОЙ проблеме это НЕ ОТНОСИЛОСЬ.

И вопрос КОММУНИКАЦИЙ (свой "резкий" стиль я - опущу, я - работаю на этим) и ПЕРЕДАЧИ знаний - как мучала меня ещё лет 10-ть назад - так и мучает. Непонятно, что с этим делать. Другие коллеги говорят - "пиши документацию". Я правда спрашиваю - "какую именно" и на этом обычно разговор - заканчивается. Потому что ответ - обычно не находится. Документов то - МНОГО. Но на КОНКРЕТНЫЕ сиюминутные вопросы - НЕПОНЯТНО как там найти ответ.

Но! в Этом КОНКРЕТНОМ случае - мне коллега сказал - "я почитал документацию. Там "почти" всего хватает". "Хорошая документация" - сказал он. Ну как-то так. При том, что эту документацию как раз НЕ Я писал. Мне тут "гордится" нечем. Я как раз там просил других коллег написать - как ОНИ это понимают. Ну чтобы не было такого - "ну тут всё понятно..."

И ВСЁ РАВНО - я НЕ ПОНИМАЮ - как передавать знания и как правильно читать чужие комментарии, в которых УЖЕ СОДЕРЖИТСЯ ответ.

Если я ОДИН такой - это пол-беды. Но что-то мне подсказывает, что это проблема ОТРАСЛИ.

Извините, если отвлёк ваше внимание без дела.

P.S. Другой коллега. Правда уже бывший. Прочитав сей пост спросил - "ну и долго ты его по-ложному следу водил?" Это он тоже кстати "не со зла" :-) Просто - УДИВИЛСЯ.

15. RUMTMARC : Договариваемся с коллегами о порядке коммитов и использовании общих библиотек (AL)

Предыдущая серия была тут - http://18delphi.blogspot.com/2013/04/14-rumtmarc-al.html

Или у нас коллег с общими библиотеками нет? Или с ними УЖЕ всё давно договорено?

Следующая серия - http://18delphi.blogspot.com/2013/04/16-rumtmarc-uml.html

"Я же вам говорил!"

"Я же вам говорил!"

Это - неправильная фраза при согласовании ТЗ. А особенно для разработчика.

А особенно - когда он таки - оказался прав по результатам разработки.

Всё равно - ничего кроме негатива - она не несёт.

Не надо её использовать. Не надо "дразнить гусей". Это фраза не для разработчиков. Для КОГО УГОДНО, но только НЕ ДЛЯ разработчиков.

Просто - "поставьте себе галочку". Или напишите assert.

Я сам неоднократно пользовался этой фразой. Поверьте мне. И кроме негатива - я так ничего и не заработал.

И если услышите её из моих уст - напомните мне про этот пост.

P.S. эту фразу можете оставить только для САМЫХ БЛИЗКИХ ДРУЗЕЙ. Они вас наверное поймут.

О ТЗ, цейтноте и "позабывании"

Фрейд З. ЗАБЫВАНИЕ ИНОСТРАННЫХ СЛОВ
Фрейд З. Психопатология обыденной жизни
З. Фрейд. Введение в психоанализ. Лекции >> Забывание имен собственных и иностранных названий, а также иностранных слов тоже можно свести к противоположному намерению, которое прямо или косвен...
Непроизвольная память

Людям свойственно забывать. Всем. Это - аксиома.

Руководству, дизайнерам, аналитикам, заказчикам (stakeholder'ам короче) - иногда свойственно не отвечать на ВСЕ заданные вопросы. Это - допущение. Если у вас не так - вам повезло. Тогда это пост не для вас. Не читайте. Спите спокойно.

Но! Часто бывает ситуация, когда ТЗ передано в разработку, но оно вызывает вопросы.

Делайте свою работу честно.

Нет ничего более ужасного, чем недовыясненные вопросы спрятанные в глубины вашего гениального кода. Его всё равно никто не оценит.

Уважайте своих коллег, которые придут "лет через десять после вас".

ЗАДАВАЙТЕ ВОПРОСЫ!

И ДОБИВАЙТЕСЬ ответов на них.

Если в процессе реализации ТЗ у вас возник вопрос требующий ответов stakeholder'ов, то для того, чтобы сохранять состояние "потока" и при этом НЕ СНИЖАТЬ темп разработки - я советую вам следующее:

1. Задайте вопрос.
2. УБЕДИТЕСЬ, что он дошел до адресата.
3. Напишите ASSERT. Да, да! Банальный assert с условием, которое вам непонятно.
4. Сформулируйте в комментариях к коду СУТЬ вопроса.
5. Укажите ДАТУ и время задания вопроса. По CVS это будет сделать муторно, да и лень.
6. Укажите номер "тикета" в базе данных или дайте ссылку на обсуждение, если оно проходит в электронном виде.
7. Предусмотрите более-менее вразумительное сообщение в лог для пользовательского варианта системы. ОТКЛЮЧАЙТЕ ASSERT'ы в пользовательском варианте системы.
8. Напишите - EXIT. Вдруг там дальше вы написали ёщё какой-то свой гениальный код.
9. Ждите ответа на вопрос и продолжайте реализацию ТЗ.
10. Если в течении "разумного" времени вы не получили ответа - дополните комментарий к коду подробностями - "когда, кто и где".
11. Если вы не получили ответов - закрывайте задачу и передавайте её в Группу Качества. Желательно при закрытии задачи указать список недовыясненных подробностей. Может быть группа качества поможет вам. И сразу откатит задачу с указанием подробностей.
12. Если вы получили ответ на вопрос - скажите "спасибо" тому, кто его дал. Ведь он - "сделал часть вашей работы".
13. Удалите ASSERT.
14. Напишите вменяемый код, учитывающий данный вам ответ.
15. Напишите тест - этот аспект системы занял не только ваше время и нервы, но и чужие. Он УЖЕ СТОИТ того, чтобы быть покрытым тестом.
16. Спите спокойно, пока какой-нибудь ASSERT не разбудит вас.

Попробуйте. Может вам понравится.

Сразу предупреждаю - может не понравиться stakeholder'ам. Но я бы - всё равно попробовал.

В конце концов - они честно делают свою работу , делайте и вы. Честно. И ДУМАЙТЕ о тех, кто придёт вам на смену. Они могут оказаться не такими гениальными как вы.

И если вы думаете - "ах у меня 800-т незаконченных задач. Ах как мне трудно.." Посмотрите сюда:

это - самоирония... если что...

P.S. Есть и альтернативные сценарии. Но все они по-моему - менее выигрышные.

Вот как я их вижу:
1. Не задавать вопросы и полагаться на свои силы. Не считайте себя черезчур гениальным.
2. Не задавать вопросы и оставить всё как есть. По-моему - в не думаете о будущем.
3. Задать вопросы и переключится на другую задачу. Тут тратим силы и время на переключение контекстов и выход из одного "потока" и вход в другой. Это - затратно.
4. Задать вопросы и ждать все ответы на них. И ничего не делать. Я - так не умею. Я сразу начинаю мучатся безделием и терять уважение к самому себе.
5. Вернуть ТЗ на доработку и забыть о нём. "Пока эта вся бюрократия раскачается". Это - самый неконструктивный путь. Если вы выбираете его - подумайте - стоит ли вам работать программистом. "Просто получать деньги" - можно и в другом месте. Например на Forex. Или в других "мыльных пузырях".