Итак, ни для кого, наверное, не новость, что бывают случаи, когда к разработчикам появляется ряд вопросов, например:
- Почему не уложились в сроки?
- Почему это сделано так, а не как в ТЗ?
- Чем ты занимался?
и т.д..
Причиной этих вопросов и многих подобных может быть «неправильное» взаимодействие с менеджером или менеджерами, над задачами которых вы работаете.
Чтобы таких вопросов не возникало и для того, чтобы вам всегда было что ответить, нужно к таким случаям всегда быть готовым и готовиться нужно заранее, выполняя дальнейшие инструкции, которые, на мой взгляд, помогут в дальнейшем избежать или отвести от вас удар.
Итак, несколько правил, которые всегда необходимо выполнять:
- Всегда на проектную задачу должно быть ТЗ, сделанное менеджером проекта. Я думаю смысл вполне ясен, но всё же:
- данный документ упростит вам разработку,
- вам не надо будет объяснять тестировщикам, что и как должно работать,
- вы сможете ответить на вопрос почему вы сделали так, а не иначе
Проектная задача без ТЗ – самоубийство: в любой момент вам могут сказать, что вы сделали не так как надо и вам нечем будет прикрыться.
-
Если проектная задача находится в процессе активной разработки, а менеджер просит отклониться от ТЗ, то обязательно убедитесь, что данные отклонения попали в ТЗ. Если вы уже сделали ту часть работы, которую затрагивают изменения, то просите менеджера поставить отдельную задачу в системе учёта и постановки задач и выделить на неё дополнительное время.
Не соблюдение правила грозит тем, что вы возможно затратите времени больше положенного и опять же не сможете в последующем объяснить почему сделано так, а не как в ТЗ.
- Каждая задача (проектная, суппортная) должна быть поставлена не устно, а в системе постановки и учёта задач. Если такая система не используется, то должно быть письмо по корпоративной почте.
Не соблюдение правила грозит тем, что вы не сможете подтвердить то, что конкретные ваши действия были вызваны не вашими собственными побуждениями и не сможете подтвердить, что вообще работали в это время, например, при заполнении каких-нибудь отчётов.
- Любая переписка будь то корпоративная почта или сообщения в клиентах мгновенных сообщения наподобие ICQ, Mai.ru Agent, Yahoo и т.п. должна сохраняться на продолжительное время. Год как минимум.
- Никогда не делайте задачу, если её должны делать не вы. Например, если вы веб-разработчик, то конечно обладаете базовыми знаниями вёрстки, но в случае, если требуются даже малейшие правки по вёрстке, просите для этих задач верстальщика.
Это позволит сократить время вашей работы и уложиться в срок.
- Любой функционал перед показом клиенту должен быть протестирован и должно быть добро от тестировщиков. Если менеджер настаивает на том, чтобы не дожидаться результатов тестирования, то обязательно получите от него подтверждение о том, что ответственность за возможные последствия по предоставления непротестированного продукта он берёт на себя.
- В случае овертаймов по просьбе менеджера обязательно требуйте письменного подтверждения от менеджера.
- Не соглашайтесь делать доработки по задаче пока не закрыты баги по ней и она не принята клиентом.
Вполне возможно, что при внесении доработок может пострадать основной функционал, относящийся к задаче и выйдет так, что вы не сделали основную задачу.
- Ни в коем случае напрямую не соглашайтесь общаться с клиентом. Да, да, есть такие менеджеры, которые просят разработчиков самостоятельно узнать ответы на все интересующие их вопросы.
Несоблюдение правила грозит тратой времени, ну и вообще не стоит делать за других их работу.
- Если по казалось бы небольшой части задачи у вас возникло более 5 вопросов, значит вы читали не ТЗ. Просите ТЗ.
- Никогда не работайте по оценке сделанной другим разработчиков или менеджером. Работать нужно только по своей оценке.
Несоблюдение правила грозит «растратой» часов. Случается, когда оценивал задачу старший или ведущий разработчик, а реализовывать её отдали простому или младшему разработчику не знакомому с проектом.
- Не ведитесь на фразы типа «некогда», «потом» и т.д..
Эти правила не являются абсолютными и объективными, выработаны на основе собственного опыта и честно говоря я их почти не применяю.
Правда к команде разработки, в которую вхожу я, по причине не применения подобных правил по одному из проектов претензии предъявили спустя год после сдачи в суппорт.
А ко мне и коллеге по другому проекту сейчас, когда он должен быть закончен, но мы не укладываемся в сроки, потому что работаем по чужой оценке.
