Блог

На прошлой неделе мы всей командой собрались на первый тренинг в компании. Не люблю это слово, но лучше ничего не нашёл. Извиняйте.Так вот, тренинг мы посвятили, пожалуй, самому актуальному вопросу среди разработчиков и руководителей отделов: как ставить, распределять и контролировать задачи без шишек и обиняков. Что отвечали, о чём дискутировали и при чём здесь любвеобильные клиенты – читаем ниже. Поехали!


Вместо длинных слов


Как веб-разработка, так и highload-разработка – процесс сложный с кучей шишек и болячек. Ничего с этим не поделаешь, просто нужно принять это как должное. Вопрос в том – как извлечь пользу от тех, кто их уже набил, для тех, кто только в пути. Передаём несколько практичных советов от руководителя нашего отдела высоконагруженных систем Григория Казакова.



 

Поставишь меня на место?


 

1. «Порядок не для галочки». Структурируйте всю свою проектную документацию, чтобы её можно было легко найти и сослаться на неё. Тоже самое относительно задач в корпоративном портале и рабочего стола постановщика: каждой задаче своя группа, каждому файлу свою папку.


 

2. При постановке задач опирайтесь на рукописный или печатный текст: техническое решение (ТР) или тезисы из него, сокращённую версию технического решения под себя или текст под конкретную задачу.


 
3. Прежде чем включить тезисы в техническое решение или в описание задачи, определите их по степени важности. Мы выделяем три типа:


 

- a) очевидные для любой реализации. Например, задача «Реализовать хранение настроек оплаты в один клик» требует реализации возможности ввода/хранения/вывода/редактирования данных;


 

- б) лже-очевидные для любой реализации. При написании тезисов иногда мы забывали ставить пометки. Через несколько месяцев, когда задачу предавали на разработку, некогда очевидные тезисы становились неочевидными;


 

- в) алгоритмы реализации, относящиеся к конкретному типу задачи. Такой тип требует обязательного описания или хотя бы упоминания, а также проработки с указанием примеров. Лучше потратить две минуты сразу, чем судорожно вспоминать потом – что же подразумевалось в этом месте?


 
Намотать на ус:


 

1. Пункт A может не иметь подробного описания. Достаточно ограничиться обычной реализацией возможности ввода/хранения/вывода/редактирования данных. 
 
2. Пункты Б и В обязательно должны иметь описание в задаче/документе.
 



4. Снабжайте проектную документацию схемами, графиками, рисунками. Так вы облегчите жизнь не только заказчику, но и себе. Согласитесь, глазу куда приятнее смотреть на картинки и графики, чем на талмуды восьми шрифтового текста.


 

5. Структурируйте любую сложную логику в бизнес-схемы. Если вы постановщик задачи – узнайте всё об описываемом бизнес-процессе, делайте заметки, рисуйте схемы. Поверьте, они придут на помощь при первом же споре с заказчиком.


 
Что должен уметь постановщик задач?


 

1. Структурировать задачу и ход её реализации у себя в голове. Только после этого разбивайте задачи части и делегируйте их программистам.


 

2. Хорошо, если постановщик отмечает все тонкости реализации в тексте самой задачи, конкретизирует  её под уровень знаний программиста. Так мы снижаем риски просрочить «горящий» проект и наткнуться на «дубляж».


 

Пример: при постановке задачи «Разработать механизм расчёта рейтинга»  попробуйте добавить пометку «разработать отдельную задачу в службе и хранимую процедуру пересчёта рейтинга, вызываемую из службы».


 

3. Чувствовать разработчиков. Да, это не опечатка. Лучший скилл постановщика  - увидеть проблемные места в задаче и степень её понимания разработчиками.


 

4. Проверяйте статус задачи в процессе разработки и по её завершении.  Даже у опытных программистов. При каких-либо недоработках есть шанс вовремя вернуть её тестировщику.


 

Пример: используется не тот компонент. Вместо «select» используется «input», вместо «автокомплита» используется select или вообще нестилизованный компонент.


 

5. Делитесь опытом, наработками, повышайте навыки собственных специалистов, если вы руководитель отдела. Ищите что-то в Google – сохраните статью в закладках или на компьютере. Не факт, что она понадобится именно сейчас, но в будущем возможно всякое. Организуйте что-то типа архива со «статьями до востребования». Таким способом на проекте для «Сбербанка» мы нашли достаточно материала по «sql-dependency», «xml-dependency», «ms sql fulltext search» и т.п.


 

6. Разбивать задачи на части. При структурированном техническом решении задачи, как правило, совпадают с пунктами ТР.


 

7. Для контроля или самоконтроля закрашивайте документ с требованиями. Черкайте, рисуйте, закрашивайте весь реализованный функционал на листах бумаги.



Да делегируйте вы уже её


 

Без всяких измудрений – просто делигируйте задачи. В нашем отделе высоконагруженных систем мы поступаем следующим образом: 


1. Задачи пониженной сложности отдаём молодым и только что пришедшим на проект сотрудникам. 


2. Задачи средней сложности (разработка функционала без привлечения к проектно-оценочной части) отдаём матёрым разработчикам.


3. Задачи повышенной сложности (проектирование функционала и оценка) выполняют матёрые + руководитель отдела. 


 

Постскриптум 


Как и обещали, несколько слов о двух «антагонистах» – любвеобильных клиентах и разработчиках. Таковы уж особенности профессии программиста, что он мало что знает о клиенте, для которого приходится запиливать очередную фичу, а для кого-то выпиливать баг. Схема работа практически всегда одна и та же: менеджер проектов сказал – руководитель показал – программист сделал.


Во второй части нашего тренинга коммерческий отдел пытался прорвать информационную блокаду программистов и объяснить: как работать в команде и приносить клиенту счастье, как привести уравнение «довольный клиент=счастливый программист» к общему знаменателю. Что в итоге из этого получится – смотрите в нашем «Портфолио».


Автор: Григорий Казаков, руководитель отдела высоконагруженных систем


Возврат к списку