Просмотр сообщений
1
Управление Проектом / Re: TeamLeader + Manager Project для управления проектом, командой и графиком работы
« : 17 Апреля 2015, 14:48:16 »
Павел, приветствую.
Попробую дать парочку "своих" откровений на Вашу ситуацию.
Совмещать в себе кучу ролей можно, но как говорится "лишь бы было". Ибо по каждому направлению частенько и целого человека на полный рабочий день мало. Это надо понимать.
Теперь что относится к роли аналитика. Заказчик (как уже ранее говорилось) конечно есть и это Вы. По идее это прекрасно, ибо во всех компромиссных ситуациях сами с собой вы быстрее договоритесь (в связке заказчик-аналитик-тимлид-продактменеджер). Ну и знания для принятия решения в одной голове, это приятный бонус.
Перейдем к требованиям. Можно разделять два процесса: процесс сбора/создания решения и процесс описания/документирования решения. Вы частенько упоминали про UML и тд, но это всего-лишь нотация оформления (для кого-то и мышления. но не суть). Т.е. для начала Вы должны представлять себе решение, а уже потом оформлять его. У меня бывало, что на поиск решения могли уходить недели (грязного времени), а на документирование 10 минут. За 5 лет работы мне так и не пришлось оформлять требования в UML-нотациях. Это я к тому, что совсем не в обязательном порядке чему-либо следовать (хотя UML/IDEFx/BPMN наверное ближе всех к стандартам отрасли).
Мы работаем с коробочным продуктом, где мои ТЗ это добавление/изменение/удаление некой части возможностей продукта.
Я передаю команде разработчиков документ (MS Word), внутри которого:
1. Тема и идентификатор задачи.
2. Исходная ситуация. Описание как мы докатились до того, что требуется что то программировать.
3. Цель. Описание цели, к чему стремимся на высоком уровне (ответ на вопросы "почему/зачем", а не "что/как"). Желательно, что бы цель не ограничивала решение. Решение - это лишь конкретный вариант достижения цели.
4. Требования. Тут у меня нумерованный список, где чем выше уровень тем в более общем смысле описана задача. Ну, например, "1. Добавить отчет "Показатель АБВ". 1.1 Параметры/настройки построения. 1.2 Выборка данных. 1.3 Макеты представления" и тд. Чем глубже - тем больше деталей. Там могут встречаться таблицы, схемы, макеты (рисую в пейнте ^^, моделирую в Visio, Excel-е и тд). Т.е. нумерованный иерархический список + материалы. Было время, начальник не принимал ТЗ "без картинок" =)
5. Миграция БД. Как обновлять БД имеющихся клиентов после обновления программы.
6. Сценарии использования/Приемочные критерии. В помощь QA-инженерам.
7. История изменений. Табличка, где вписаны жизненные вехи документа (создание, правки и т.д.).
Некоторые пункты можно пропускать в тех или иных случаях. Я привел пример "своей рыбы", думаю на её базе Вы уже сейчас сможете начать оформлять свои мысли. Разумеется "рыба" у каждой команды и продукта своя, Вы со временем придете к своему варианту, надо только сделать первый шаг.
Предварительно необходимо составить vision (главный концепт) вашей игры. Не забывайте ключевые принципы, типа "Разделяй и властвуй". Не можете оценить задачу - дробите на составляющие. Ну и в этом духе, от общего к частному и наоборот. А так же ознакомиться с азами системного подхода. Удачи!
Попробую дать парочку "своих" откровений на Вашу ситуацию.
Совмещать в себе кучу ролей можно, но как говорится "лишь бы было". Ибо по каждому направлению частенько и целого человека на полный рабочий день мало. Это надо понимать.
Теперь что относится к роли аналитика. Заказчик (как уже ранее говорилось) конечно есть и это Вы. По идее это прекрасно, ибо во всех компромиссных ситуациях сами с собой вы быстрее договоритесь (в связке заказчик-аналитик-тимлид-продактменеджер). Ну и знания для принятия решения в одной голове, это приятный бонус.
Перейдем к требованиям. Можно разделять два процесса: процесс сбора/создания решения и процесс описания/документирования решения. Вы частенько упоминали про UML и тд, но это всего-лишь нотация оформления (для кого-то и мышления. но не суть). Т.е. для начала Вы должны представлять себе решение, а уже потом оформлять его. У меня бывало, что на поиск решения могли уходить недели (грязного времени), а на документирование 10 минут. За 5 лет работы мне так и не пришлось оформлять требования в UML-нотациях. Это я к тому, что совсем не в обязательном порядке чему-либо следовать (хотя UML/IDEFx/BPMN наверное ближе всех к стандартам отрасли).
Мы работаем с коробочным продуктом, где мои ТЗ это добавление/изменение/удаление некой части возможностей продукта.
Я передаю команде разработчиков документ (MS Word), внутри которого:
1. Тема и идентификатор задачи.
2. Исходная ситуация. Описание как мы докатились до того, что требуется что то программировать.
3. Цель. Описание цели, к чему стремимся на высоком уровне (ответ на вопросы "почему/зачем", а не "что/как"). Желательно, что бы цель не ограничивала решение. Решение - это лишь конкретный вариант достижения цели.
4. Требования. Тут у меня нумерованный список, где чем выше уровень тем в более общем смысле описана задача. Ну, например, "1. Добавить отчет "Показатель АБВ". 1.1 Параметры/настройки построения. 1.2 Выборка данных. 1.3 Макеты представления" и тд. Чем глубже - тем больше деталей. Там могут встречаться таблицы, схемы, макеты (рисую в пейнте ^^, моделирую в Visio, Excel-е и тд). Т.е. нумерованный иерархический список + материалы. Было время, начальник не принимал ТЗ "без картинок" =)
5. Миграция БД. Как обновлять БД имеющихся клиентов после обновления программы.
6. Сценарии использования/Приемочные критерии. В помощь QA-инженерам.
7. История изменений. Табличка, где вписаны жизненные вехи документа (создание, правки и т.д.).
Некоторые пункты можно пропускать в тех или иных случаях. Я привел пример "своей рыбы", думаю на её базе Вы уже сейчас сможете начать оформлять свои мысли. Разумеется "рыба" у каждой команды и продукта своя, Вы со временем придете к своему варианту, надо только сделать первый шаг.
Предварительно необходимо составить vision (главный концепт) вашей игры. Не забывайте ключевые принципы, типа "Разделяй и властвуй". Не можете оценить задачу - дробите на составляющие. Ну и в этом духе, от общего к частному и наоборот. А так же ознакомиться с азами системного подхода. Удачи!