Стать менеджером IT-проекта довольно сложно. И, думаю, не у меня одного появилась проблема с написанием первого технического задания. Но, давайте по порядку. Какие знания и навыки я имел перед началом работы?
На данный момент я являюсь студентом, уже закончившим 3 курс Санкт-Петербургского государственного электротехнического университета «ЛЭТИ». Учусь на кафедре автоматизации процессов управления (АПУ) по специальности информационные системы и технологии в бизнесе. Фактически из меня клепают менеджера проектов, запихивая в голову знания по базам данных, нереалиционным системам, программированию (в основном JAVA и С++ на первых курсах), процессов управления и контроля проектов.
В процессе обучения на двух дисциплинах нам уже давали собирать требования по системе и писать по этим требованиям ТЗ. Но, думаю, вы представляете, как они собирались и как проверялись. Учитывая, что все ограничения мы (студенты) придумывали сами, функционал системы был очень простой. Плюс мы не сильно парились на тему финансовой выгоды будущего продукта.
Однако из этих курсов мой были получены навыки работы с UML и в голове держался образ структуры технического задания в целом. С чего начать, что делать и к чему прийти. Это и помогло мне начать.
Что представляет собой компания, которая взяла такого недоработника и какие задачи она передо мной поставила?
На 3 курсе (а то и раньше) я уже начал понимать, что в университете мне на дадут достаточных для работы навыков, чтобы при его окончании я был полезен компании, которая меня приютит. И по-этому перед мной появилось два пути для получения достаточного количества опыта, чтобы годно нести звание руководителя IT-проектов.
Итак, о каких путях идет речь?
1. Начать свой стартап.
2. Устроится в компанию уже сейчас, работая бесплатно на опыт, пока не начну приносить хоть маломальскую пользу (рабская стажировка).
Первый вариант, несмотря на то, что идей для стартапа в голове много, отлетел сразу, как появился приблизительный ценник того, во сколько он мне обойдется. Будучи студентом ты сильно ограничен бюджетом и довольно опасно не имея опыта и даже представления, как это реально работает, вкладываться в такое дело. Прибыльным, во всяком случае, оно вряд ли ли станет.
Второй же вариант оказался идеальным для моего университета и кафедры в целом.
Дело в том, что моя кафедра сотрудничает с компанией «АЛЕЕ СОФТВЕР». Представители данной компании не только преподают у нас в вузе, предлагая студентам практические навыки и опыт, но и с удовольствием стажируют «лучших» у себя в компании. В эту компанию я и обратился.
Конечно же мне дали для начала самое простое из заданий в фирме. Цель: переписать web-клиент системы под новый фреймворк с добавлением новых функциональных возможностей.
С чего началась моя работа?
Этап 1. Для начала мне рассказали про систему. Что она собой представляет, какие проблемы она решает и как она работает. Это было что-то вроде 4-х часовой лекции по основам ERM системы и истории продукта. Далее мне дали мануал по системе, в котором я разобрался более подробно в ее текущем функционале. К слову, система имеет два клиента: web и desktop. Причем функционал второго был шире текущего функционала первого. Документация имелась только на desktop версию, да и то, как справочник по работе с системой для клиентов. Технические задания по системе были утеряны.
Этап 2. После, ознакомившись с мануалом и перечитав все записи после лекций о системе, я начал структурировать полученные знания. Целью данного шага для меня стало написание некого документа, в котором были бы написаны ответы на вопросы: «что?» (за система), «зачем?» (она создана), «как?» (она работает). На данном этапе я получил нечто вроде документа, презентующего текущий продукт. В нем описывались цели клиента, как клиенты видит эту систему и почему клиент должен купить именно нашу систему (ее особенности). Думаю, это из-за того, что по своей натуре я продажник и для меня основной вопрос «зачем это покупать?». Документ был похож на «спецификацию требований», но отличался от университетских курсовых работ, в которых мы писали спецификацию. Был написан более простым языком и не имел четких разделов. Лаконично и самое основное. Как мне показалось, его было достаточно, чтобы перейти к следующему шагу.
Этап 3. UML-диаграммы, все как «по-учебнику». На диаграмме вариантов я отобразил пользователей и что они хотели бы видеть в системе.
После, как я думаю, и пошли мои ошибки. Я сразу перешел от описания функционала, перескочив описание данных и то, как эти функции работают, к описанию интерфейсов. Из-за этого, во время описания интерфейсов появлялись логические ошибки. Не понимая, как хранятся данные, я «нафантазировал» интерфейс для web-клиента, в котором клиент получил бы самый тормозящий функционал из всех, что он видел.
Этап 4. Доработка. Последние три этапа длились около 1,5 месяца, когда четвертый этап длился больше 2. Я всех достал в офисе.
Сначала я переписывал функционал и дорисовывал интерфейсы. Так как это был мой первый проект, я не имел даже малейшего представления, что важно описать все-все ошибки, все-все иконки. Нужно, чтобы заказчик знал, что может сделать каждая кнопка в программе еще до ее написания. Мне пришлось изучить Gui-machine, программу, созданную в моей компании, в которой можно создавать динамические интерфейсы. Программа полезная, но привыкал я к ней долго. После того, как я исправил логические ошибки, нужно было править язык и структуру ТЗ. В университете на это закрывали глаза, так как проекты не превышали 50 страниц. Но тут серьезное задание и я себя переоценил. Речь была слишком простой, терялась логика в заголовках. Я постоянно скакал от функции одного актера к функциям другого. В скринах интерфейса люди терялись, переставая понимать что за чем идет.
Немного стыдно это писать. Я довольно много работал над ТЗ и вкладывал в него много сил и времени, но оно все равно оказалось сырым. Мою работу приняли, но меня перевели в отдел маркетинга.
Что я извлек для себя?
1. Я понял, как нужно писать ТЗ, чтобы оно было читабельным.
2. Увидел на что нужно акцентировать внимание.
3. Самое главное в ТЗ это структура. Ее нужно иметь везде.
И самое главное, я понял, что ТЗ пишется не для себя. ТЗ пишется для других.
Буду рад услышать ваши фейлы и неудачи в работе, когда вы только начинали и то, как вы с ними справлялись.
Автор: devays
