Фрейд З. ЗАБЫВАНИЕ ИНОСТРАННЫХ СЛОВ
Фрейд З. Психопатология обыденной жизни
З. Фрейд. Введение в психоанализ. Лекции >> Забывание имен собственных и иностранных названий, а также иностранных слов тоже можно свести к противоположному намерению, которое прямо или косвен...
Непроизвольная память
Людям свойственно забывать. Всем. Это - аксиома.
Руководству, дизайнерам, аналитикам, заказчикам (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. Или в других "мыльных пузырях".
Фрейд З. Психопатология обыденной жизни
З. Фрейд. Введение в психоанализ. Лекции >> Забывание имен собственных и иностранных названий, а также иностранных слов тоже можно свести к противоположному намерению, которое прямо или косвен...
Непроизвольная память
Людям свойственно забывать. Всем. Это - аксиома.
Руководству, дизайнерам, аналитикам, заказчикам (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. Или в других "мыльных пузырях".
Комментариев нет:
Отправить комментарий