AXForum  
Вернуться   AXForum > Microsoft Dynamics NAV > NAV: Функционал
NAV
Забыли пароль?
Зарегистрироваться Правила Справка Пользователи Сообщения за день Поиск

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 24.08.2011, 17:32   #1  
Константин! is offline
Константин!
Участник
 
180 / 10 (1) +
Регистрация: 13.04.2005
Адрес: Казань
Добрый день Коллеги! Очень интересует ваш опыт организации работы группы программистов по внедрению и поддержке navision.
Расскажу о том как это работает у нас и какие проблемы у нас возникают.
В штате 4 программиста, руководитель группы программистов - (это я), 1 консультант, 1 консультант - руководитель проекта и 1 директор.

В работе 6 проектов:
1 проект это новое внедрение, на стадии завершения
3 проекта на тех поддержке
1 проект тех поддержка + разработка крупных модулей (отдельные проекты)
1 проект по любви (Сами на навике работаем)

Для каждого клиента организован отдельный интернет портал на sharepoint где они заносят нам задачи на разработку, проставляют срочность и тд.В портале ведется переписка разработчика с клиентом по конкретным задачам.У нас это работает только на проекты с тех поддержкой и иногда в конечной стадии внедрения когда необходимо с клиента собрать финальный список хотелок. Ежемесячно по порталу клиенту предоставляется отчет по выполненным задачам.

Задачи программистам могут поступать:
1)от руководителя группы программистов
2) от консультантов
3) от сотрудников клиента по телефону
4) от клиентов в портале
5) прибегает директор и кричит, "надо сделать срочно иначе все пропало".

В результате мне как руководителю группы , отследить и упорядочить работу практически не возможно. Иногда не понятно, что делает каждый программист и когда он должен закончить работу. Если не нагрузить программиста задачами по самые уши, как только он закончит текущею задачу, не зачто не скажет что он закончил и будет бездельничать.А чтобы грамотно поставить задачу на весь день, мне нужно весь предыдущей день готовить тз В результате производительность отдела падает.Если же тз ставить на лету, то результат который выдаст программист, не всегда будет устраивать.
Я как руководитель группы совмещаю в себе консультанта и в офисе сижу в лучшем случае пол дня, остальные пол дня у клиента, обсуждаю технические стороны новых крупных задач. Если меня нет в офисе, работа у программистов почему замедляется )

Пытаемся начать работать по следующей схеме.
Вечер предыдущего дня: руководитель группы подготавливает список задач на следующий день для каждого программиста.
Утро текущего дня: совещание с программистами , на котором перед каждым ставится объем работ на день.
Заявки полученные в течение дня копятся для анализа руководителем вечером.
Вечер Подготовка задач руководителем на следующей день.
Недостатки: некому отвечать на звонки клиентам, нельзя оперативно удовлетворять заявки.

Но закралась мысль, что я сижу и изобретаю велосипед. У кого как построена работа по контролю и постановке задач программистам?
Старый 24.08.2011, 18:36   #2  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Цитата:
Сообщение от Константин! Посмотреть сообщение
отдельный интернет портал на sharepoint...
ой! отдельный? а потом сводить как в единое?
возьмите любой таскменеджер. хоть бесплатный http://www.mantisbt.org/ (хотя это и не самый лучший вариант)
но чтобы задачи были в одной базе.

должна быть возможность анализа с двух сторон:
1. со стороны проекта/клиента к ресурсам
2. со стороны ресурсов к проектам/клиентам

сейчас у вас похоже только первая сторона.

Цитата:
Сообщение от Константин! Посмотреть сообщение
...где они заносят нам задачи на разработку, проставляют срочность и тд.
...А чтобы грамотно поставить задачу на весь день, мне нужно весь предыдущей день готовить тз
ой, второй раз.
дело в том, что программисты и клиенты говорят на разных языках.
= клиенты (пользователи) говорят на языке предметной области.
= программисты говорят на языке объектов системы

http://forum.mazzy.ru/index.php?showtopic=1063
http://axforum.info/forums/showthread.php?t=17884

консультант - переводчик с одного языка на другой, и обратно (по определению ).
программист, который умеет говорить на языке клиента скорее редкость, нежели правило.
поэтому, на мой взгляд, вряд ли стоит воспринимать работу по подготовке ТЗ как непроизводительные затраты времени (но! см. ниже).


Цитата:
Сообщение от Константин! Посмотреть сообщение
В результате мне как руководителю группы , отследить и упорядочить работу практически не возможно. Иногда не понятно, что делает каждый программист и когда он должен закончить работу. Если не нагрузить программиста задачами по самые уши, как только он закончит текущею задачу, не зачто не скажет что он закончил и будет бездельничать.В результате производительность отдела падает.Если же тз ставить на лету, то результат который выдаст программист, не всегда будет устраивать.
мне кажется, что неправильно воспринимать программистов как балбесов и разгильдяев (хотя есть и такие)
мне кажется, что не стоит регламентировать каждый час работы программиста (вот это точно непроизводительно)

у программиста должен быть некий фронт работ,
1. сформулированный на понятном ему языке
2. с явно заданными критериями проверки (как программист может проверить правильность того, что сделал?)
3. с явно заданными приоритетами (если прибегает директор и чего-то кричит, то никому не возможно "отследить и упорядочить работу")

и тут, на мой взгляд, проявляется ограниченность выбранного вами инструмента.
большинство таскменеджеров умеют декомпозировать задачи, а стандартный sharepoint работает только с плоскими задачами без подзадач (могу ошибаться)

другими словами:
  • задачи, сформулированные клиентом на языке предметной области, ДОЛЖНЫ декомпозироваться на подзадачи (такую декомпозицию вряд ли сделают программисты)
  • подзадачи, сформулированные на языке программистов, могут и ДОЛЖНЫ оцениваться программистами
  • между подзадачами хорошо бы иметь связи (зависит/дублирует/связан)
  • для задач ДОЛЖНЫ быть сформулированы критерии проверки (хорошо бы и для подзадач, но это уже достаточно трудоемко)
  • не стоит стремиться к "точной" почасовой оценке каждой подзадачи - такая оценка слишком трудоемка и, как правило, дает очень высокую погрешность. лучше планировать с точностью до дня. лучше запланировать 3 задачи в один день, нежели 3 задачи по 2,5 часа каждая. Если хороший программист, то с точностью до недели - 5 задач за неделю в любом порядке на выбор программиста.

тут конечно важно не забывать о "гарантированном сроке ответа" на вопросы клиентов, если такое прописано в договоре с клиентом.
но и здесь - вместо того, чтобы диктовать "с 9:00 до 10:00 - подвиг" лучше прописать, что программист должен ответить не менее чем на Х срочных запросов в неделю. но это уже тонкости. главное - не стоит пытаться диктовать с точностью до минут/часов - с программированием так не получается.
__________________
полезное на axForum, github, vk, coub.
Старый 24.08.2011, 23:55   #3  
Yoil is offline
Yoil
NavAx
NavAx Club
Лучший по профессии 2017
Лучший по профессии 2009
 
1,574 / 70 (6) ++++
Регистрация: 20.11.2002
Адрес: Msk
а какая мотивация у программистов?
жесткий фикс?
__________________
"Моей лошадке ядрышком полмордочки снесло..."
А.В.Суворов, письма к дочери
Старый 25.08.2011, 10:24   #4  
Константин! is offline
Константин!
Участник
 
180 / 10 (1) +
Регистрация: 13.04.2005
Адрес: Казань
Цитата:
Сообщение от Дуд Посмотреть сообщение
а какая мотивация у программистов?
жесткий фикс?
Да жесткий фикс. Причем опыт программирования у трех минимальный(только что из института) и их приходится консультировать постоянно. Т.е. весь объем до этого тянули два програмера в режиме аврала.
Старый 25.08.2011, 11:21   #5  
Константин! is offline
Константин!
Участник
 
180 / 10 (1) +
Регистрация: 13.04.2005
Адрес: Казань
Цитата:
Сообщение от mazzy Посмотреть сообщение

ой! отдельный? а потом сводить как в единое?
Точно, точно сводить нереально делаем отчеты по каждому порталу. Sharepoin это у нас желание директора, правда немного недостроенное и неудобное.

Цитата:
Сообщение от mazzy Посмотреть сообщение

должна быть возможность анализа с двух сторон:
1. со стороны проекта/клиента к ресурсам
2. со стороны ресурсов к проектам/клиентам

сейчас у вас похоже только первая сторона.
Цитата:
Сообщение от mazzy Посмотреть сообщение
ой, второй раз.
дело в том, что программисты и клиенты говорят на разных языках.
ну в один портал заходят и клиенты и программисты и консультанты и все пишут в рамках одной задачи.В результате то что написал программер клиент просто не понимает, а то что написал клиент не понимает программер.



Цитата:
Сообщение от mazzy Посмотреть сообщение
консультант - переводчик с одного языка на другой, и обратно (по определению ).
ой где таких косультантов найти то, зачастую консультант так запудрит мозг, что задача решается вообще в другом ключе. У нас консультан общается с пользователями, , помогает им сформулировать задачу,настраивает систему и консультируют программистов, но грамотно поставить им задачу они все таки не могут т.к. не знаю структуру ситемы.
Цитата:
Сообщение от mazzy Посмотреть сообщение
программист, который умеет говорить на языке клиента скорее редкость, нежели правило.
у нас такой пока только я (нескромно конечно), и то не с каждым бухгалтером и не на любые темы.





Цитата:
Сообщение от mazzy Посмотреть сообщение
мне кажется, что не стоит регламентировать каждый час работы программиста (вот это точно непроизводительно)
у программиста должен быть некий фронт работ,
1. сформулированный на понятном ему языке
2. с явно заданными критериями проверки (как программист может проверить правильность того, что сделал?)
3. с явно заданными приоритетами (если прибегает директор и чего-то кричит, то никому не возможно "отследить и упорядочить работу")
Абсолютна согласен.


Цитата:
Сообщение от mazzy Посмотреть сообщение
и тут, на мой взгляд, проявляется ограниченность выбранного вами инструмента.
а какой используете вы?

Цитата:
Сообщение от mazzy Посмотреть сообщение
  • задачи, сформулированные клиентом на языке предметной области, ДОЛЖНЫ декомпозироваться на подзадачи (такую декомпозицию вряд ли сделают программисты)
  • подзадачи, сформулированные на языке программистов, могут и ДОЛЖНЫ оцениваться программистами
  • между подзадачами хорошо бы иметь связи (зависит/дублирует/связан)
  • для задач ДОЛЖНЫ быть сформулированы критерии проверки (хорошо бы и для подзадач, но это уже достаточно трудоемко)
т.е. клиент создал задачу №1
консультант создал связанную задачу №1-1 и внес свои комментарии и критерии оценки результата(т.к. клиент не пишет как он будет проверять результат)
руководитель группы программистов переформулировал задачу №1-1 в задачу №1-1-1 которая сформулирована на языке объектов, плюс критерии оценки результата, тоже на языке программиста.Возможно задачу №1-1 будет необходимо разбить на несколько подзадач, что пока для меня непонятно по каким критериям разбивать. Если можно приведите пример.Задача падает к программисту он ее выполняет и в задаче №1 которую видит клиент увеличивается процент выполнения.

А как должен проходить процесс тестирования. По уму должен быть отдельный человек тестировщик, но это не по нашему бюджету. В нашем случае, задачу наверное должен проверить рук. группы. програм. а потом консультант.

Расскажите, пожалуйста как у вас устроенно.
Старый 25.08.2011, 11:42   #6  
Sancho is offline
Sancho
Administrator
Аватар для Sancho
Лучший по профессии 2017
Лучший по профессии 2009
 
1,294 / 221 (10) ++++++
Регистрация: 11.01.2006
купите одного зрелого программиста
он и молодежь отучит по кнопкам бестолку стучать (подскажет как смотреть, что все уже сделано до нас), и консультанта отучит необоснованные сроки ставить или подписываться под нереальными улучшайзерами, что хочет клиент.
зрелый программер почти конс.
зрелый конс почти программер.
тенденция должна идти (Дуд прав!) к максимизации эффективности: больше качественно закрытых (не запрограммированных! а закрытых!) задач в единицу времени.
этому четкая граница "я конс - ты кодер, вот до сюда мое - вот отсюда твое" только мешает, ибо при непонятках требует больше итераций, затрат времени.

так что задача конса не трансляция желаний клиента в код и написание тз с кодом, а рекомендации клиенту, как что ЛУЧШЕ сделать и почему такое делать не следует.

а до кодера в ОБЯЗАТЕЛЬНОМ порядке надо доносить основную, без транскрипций, мысль клиента: "в итоге он хочет тут кнопочку по которой такое сообщение"
иначе кодер пишет по ТЗ и не улавливает цель того, что он вообще делает.
Старый 25.08.2011, 12:47   #7  
Константин! is offline
Константин!
Участник
 
180 / 10 (1) +
Регистрация: 13.04.2005
Адрес: Казань
Цитата:
Сообщение от Sancho Посмотреть сообщение
купите одного зрелого программиста
Позно уже, купили троих программистов- стажеров(т.к. спецов в нашем регионе не нашли либо мало платили). Изначально мы работали Программист, Консультант, Директор. И все друг друга понимали, устраивали мозговые штурмы и все шло нормально, но кол-во проектов растет и программист стал рук. группы программистов, консультант стал еще и руководителем проекта. И началась не разбериха, те схемы которые работали в маленькой команде профессионалов не подходят для команды, где уровень знание мягко сказать разный. По этому хочется как-то оптимизировать свою работу.

Цитата:
Сообщение от Sancho Посмотреть сообщение
тенденция должна идти (Дуд прав!) к максимизации эффективности: больше качественно закрытых (не запрограммированных! а закрытых!) задач в единицу времени.
да согласен с этим.
Старый 25.08.2011, 14:52   #8  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Цитата:
Сообщение от Константин! Посмотреть сообщение
Цитата:
Сообщение от mazzy Посмотреть сообщение
ой, второй раз.
дело в том, что программисты и клиенты говорят на разных языках.
ну в один портал заходят и клиенты и программисты и консультанты и все пишут в рамках одной задачи.В результате то что написал программер клиент просто не понимает, а то что написал клиент не понимает программер.
это два.
нужно выделять подзадачи. сам бьюсь со своими - постоянно пытаются в одну кучу все свалить.


Цитата:
Сообщение от Константин! Посмотреть сообщение
Цитата:
Сообщение от mazzy Посмотреть сообщение
консультант - переводчик с одного языка на другой, и обратно (по определению ).
ой где таких косультантов найти то, зачастую консультант так запудрит мозг, что задача решается вообще в другом ключе. У нас консультан общается с пользователями, , помогает им сформулировать задачу,настраивает систему и консультируют программистов, но грамотно поставить им задачу они все таки не могут т.к. не знаю структуру ситемы.
а консультант и не должен ставить задачу с точностью до поля, кнопки или триггера.
консультант должен ставить задачу так, чтобы ее можно было проверить.

другими словами, консультант должен описывать не что нужно сделать,
а как он будет проверять сделанное.


Цитата:
Сообщение от Константин! Посмотреть сообщение
Цитата:
Сообщение от mazzy Посмотреть сообщение
и тут, на мой взгляд, проявляется ограниченность выбранного вами инструмента.
а какой используете вы?
тот же мантис http://www.mantisbt.org/
бесплатно, гибко, доступно через браузер, позволяет создавать задачи просто отправив письмо (что нравится пользователям)

но не совсем для внедренческих контор.
если бы я выбирал сейчас, то постарался бы выбрать что-нибудь другое, более функциональное.

Цитата:
Сообщение от Константин! Посмотреть сообщение
Цитата:
Сообщение от mazzy Посмотреть сообщение
  • задачи, сформулированные клиентом на языке предметной области, ДОЛЖНЫ декомпозироваться на подзадачи (такую декомпозицию вряд ли сделают программисты)
  • подзадачи, сформулированные на языке программистов, могут и ДОЛЖНЫ оцениваться программистами
  • между подзадачами хорошо бы иметь связи (зависит/дублирует/связан)
  • для задач ДОЛЖНЫ быть сформулированы критерии проверки (хорошо бы и для подзадач, но это уже достаточно трудоемко)
т.е. клиент создал задачу №1
консультант создал связанную задачу №1-1 и внес свои комментарии и критерии оценки результата(т.к. клиент не пишет как он будет проверять результат)
руководитель группы программистов переформулировал задачу №1-1 в задачу №1-1-1 которая сформулирована на языке объектов, плюс критерии оценки результата, тоже на языке программиста.Возможно задачу №1-1 будет необходимо разбить на несколько подзадач, что пока для меня непонятно по каким критериям разбивать. Если можно приведите пример.Задача падает к программисту он ее выполняет и в задаче №1 которую видит клиент увеличивается процент выполнения.
последнее неправильно. никакого автоматического закрытия!
кроме того, вы упускаете процесс проверки.

подзадача попадает к программисту, он ее выполняет.
выполненная подзадача возвращается автору подзадачи.
автор подзадачи проверяет и закрывает (или возвращает на доработку, если необходимо).

автор подзадачи является исполнителем задачи более выского уровня.
о выполнении которой он должен отчитаться. осознанно и руками.
выполненная задача возвращается заказчику. он проверяет и закрывает. или возвращает на доработку.


Цитата:
Сообщение от Константин! Посмотреть сообщение
А как должен проходить процесс тестирования. По уму должен быть отдельный человек тестировщик, но это не по нашему бюджету. В нашем случае, задачу наверное должен проверить рук. группы. програм. а потом консультант.
кто ставит задачу - тот и проверяет правильность выполненного.
__________________
полезное на axForum, github, vk, coub.
Старый 25.08.2011, 17:49   #9  
jopagames2 is offline
jopagames2
Участник
 
151 / 11 (1) +
Регистрация: 11.02.2010
Цитата:
Сообщение от Sancho Посмотреть сообщение
купите одного зрелого программиста
он и молодежь отучит по кнопкам бестолку стучать (подскажет как смотреть...
Сама идея "купить готового спеца" здравая и вполне живая.
Но! Не будем забывать, что сам Microsoft в геометрической прогрессии СОЗНАТЕЛЬНО увеличивает объём кода и сложность своего продукта. В программе постоянно возникают какие-то новые тренды.
Поэтому купить человека, который УЖЕ в теме и УЖЕ разобрался с особенностями 2009 и RTC всё сложнее и сложнее.
Цель - пресечь всякие попытки образования мелких центров решений, оставив всё на откуп крупным рыбам, которые уже умеют слажено управлять коллективом программистов.

Сама идея маленькой конторы, где есть 3 Pascal-студента, консультант, директор, стол, стул и маржа сейчас уже стала утопической.
Такое могло бы быть лет 10 назад в эпоху бума внедрения ERP (напр., контора Navisoft), но не сейчас, когда бизнес укрупняется.

Думаю так.

Хотя - пробуйте. Я так понял, что дело происходит не в 5020, а где-то, где конкуренция меньше.
В конце концов, не боги горшки обжигают!
Старый 26.08.2011, 12:24   #10  
.Quattro. is offline
.Quattro.
Участник
Лучший по профессии 2009
 
194 / 22 (1) +++
Регистрация: 22.05.2006
Цитата:
Сообщение от Константин! Посмотреть сообщение
В штате 4 программиста, руководитель группы программистов - (это я), 1 консультант, 1 консультант - руководитель проекта и 1 директор.
А чем занимается консультант-руководитель проекта? Это его работа отслеживать загрузку разработчиков.
А тот, кого вы называете "консультантом" больше смахивает на HelpDesk.
Консультант обязан знать систему.

Как я понимаю, у вас есть 2 зрелых программиста, или у вас 2 средних и 3 только из института? Обязательно должен быть один главный разработчик, который смог бы помогать неопытным.
Старый 29.09.2011, 23:04   #11  
Константин! is offline
Константин!
Участник
 
180 / 10 (1) +
Регистрация: 13.04.2005
Адрес: Казань
За прошедшие месяц запустил портал на redmine.
Пока только одни плюсы:
Получил единую точку входа для задач по всем проектам.
Вижу загрузку каждого разработчика
Время затраченное на каждую задачу.
Могу планировать задачи, и составлять план на разработку каждому программеру.
Прикольная штука если разрабатываеш какой то модуль, то можно завести версию с датой DEADLINE и привязывать к ней задачи и видеть Action План по проценту выполнения всех задач, и сколько у тебя осталось до сдачи модуля.
Есть диаграмма Ганта по задачам и подзадачам, честно скажу ВЕЩЬ.
Есть стыковка с SVN.

Следующий этап это затащить все проекты в SVN, что бы был контроль версий, пока наткнулся на утилиту NavRepository, что то не разобрался как она вытаскивает из BLOB листинг объекта, точнее она даже не смогла его вытащить. Сначала ругалась что NAVISION's COM server not registred, потом попросила открыть клиента с нужной базой, но увы так и не показала мне код объекта.
Старый 30.09.2011, 10:45   #12  
Константин! is offline
Константин!
Участник
 
180 / 10 (1) +
Регистрация: 13.04.2005
Адрес: Казань
разобрался с NavRepository . Работает только с шестеркой, у меня получилось на 6r2 classic sql. Просит установить язык в клиенте English. Т.е. выходи в шестерке появился какой то com объект которые позволяет вытаскивать код из BLOB.
 


Ваши права в разделе
Вы не можете создавать новые темы
Вы не можете отвечать в темах
Вы не можете прикреплять вложения
Вы не можете редактировать свои сообщения

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.
Быстрый переход

Рейтинг@Mail.ru
Часовой пояс GMT +3, время: 10:09.
Powered by vBulletin® v3.8.5. Перевод: zCarot
Контактная информация, Реклама.