В теме 5 ответов, и 2 участника, последнее обновление сделано пользователем 
Антон Труханёнок 9 г, 10 мес. назад.
-
Сообщения
-
Предистория: я — экономист в строительной компании (образование, соответственно, БГУ экономика и БНТУ стройфак). По совмещению на меня «повесили» функции аналитика: спецификации для программиста 1С при автоматизации ряда функций.
Мне понравилось очень-очень, теперь я сама на себя эти обязанности «навешиваю», но есть ПРОБЛЕМА: я не программист, вообще не программист, последнее, что делала по программированию — это паскаль в школе…. И я не могу оценить трудоемкость задачи и вообще, можно ли это сделать. Программист сидит в другом городе, видимся редко, общение — скайп, телефон, вьюер и т.д.
Уже бывало несколько раз, что я описывала задачу, которую с точки зрения логики можно сделать и на схемке все красиво, а на платформе 1С это оказывалось очень трудоемко или опасно. Раньше был программист, который с порога посылал с такими задачками. Если задача была важная и прям очень-очень нужная, я спорила, если нет — значит нет.
Теперь программист — очень исполнительная милая девушка, берет любую работу, даже то, что вручную сделать было бы быстрее и проще, чем автоматизировать. Конечно, я спрашиваю, сколько это может занять времени и указываю приоритеты, но приоритеты ОЧЕНЬ субъективны. Программист к тому же не склонна спорить, все делает, а потом оказывается, что если бы чуточку изменить требование — все было бы в 100 раз проще, хотя, в идеале, лучше это требование не менять.
Я хотела бы уточнить у опытных аналитиков, есть ли шанс у аналитика без ай-ти бэкграунда быстро научиться оценивать трудоемкость задач на конкретной платформе? И вообще, ваши программисты спорят с вами? Какую классификацию приоритетов вы используете, чтобы дать понять программисту, что эта задача важная, но при большой необходимости можно чуть-чуть подвинуться? Пишите ли вы т.н. предспецификацию, т.е. сначала изучение возможностей, а потом уже детальное описание, если сами возможности платформы позволяют?
з.ы. Если аналитик — бывший программист, вопрос, конечно, не актуален)))).
Шанс есть. Чтобы ощущать трудоёмкость задач, делайте декомпозицию до кусочков в несколько дней или мельче. Делайте оценки, потом сравнивайте их с фактически затраченным временем, сохраняйте для истории.Вы ставите опыт в роли разработчика во главу угла, а между тем к вашей задаче он не имеет отношения. Это задача для менеджера проекта: собрать оценки, оценить риски, расставить приоритеты. Для этого не нужно быть разработчиком, достаточно разработчика сначала научить делать оценки, затем просить его делать их.
Налаживайте контакт с вашим разработчиком. По скайпу можно нормально общаться. Поговорите «за жизнь», чтобы убрать барьер в общении, если таковой есть. Проведите тим-билдинг, сделайте что-нибудь вместе оффлайн, познакомьтесь. В итоге, донесите свои пожелания, чтобы разработчик поняла, что от неё хотят. Например, что она должна «спорить» о целесообразности реализации «фич», которые выглядят как мелочи, но требуют много времени.
К слову, мне не нравится слово «спорить» в этом контексте. Здесь уместнее будет «диалог»: разработчик доносит до менеджера цену и риски реализации «фичи», а менеджер уже решает, что делать. «Посылать с порога» звучит как-то брутально. Если сотрудник отказывается делать свою работу, то может ли он сам быть послан туда же? Если коллега отказывается выполнять поставленную задачу, и у вас нет на него влияния, обращайтесь к тем, у кого оно есть, или «эскалируйте» проблему.
О классификации приоритетов. Можете использовать MoCCoW. Но по сути названия не имеют значения. Назовите приоритеты так, чтобы всем было понятно. Например: «Обязательно» и «Желательно» (часто хватает двух приоритетов).
Можете использовать «предспецификацию» как черновик требований, без лишних деталей, только то, что нужно для оценки трудоёмкости и реализуемости. Конечно, этот подход используется, часто — в начале проекта или фазы.
Спасибо за ответ.Налаживайте контакт с вашим разработчиком.
Контакт у нас хороший:) Мне иногда кажется, что именно из-за хороших отношений она стесняется сказать, что работа слишком трудоемкая и что хорошо бы что-то убрать. Или просто не вникает в саму задачу с аналитической точки зрения, это, конечно, и не ее работа. Предыдущий программист сначала сам анализировал сущность задачи, а потом мог четко сказать, что ее реализация неэффективна. Для меня это было очень удобно.
РМ у нас нет, как и тестировщиков и т.д., мы строительная компания и автоматизация только под нужды самой организации, штат из n человек нецелесообразен.
По приоритетам — я пока указываю как часто функция будет использоваться, и для каких нужд: для управленческого учета или регулируется законодательно.
Тогда еще вопрос о непосредственно работе аналитика в «классическом» варианте. Когда вы собираете требования и пишете спецификацию, вы не учитываете трудоемкость и выполнимость задач? Т.е. задача аналитика «описать как есть» без корректировок на рациональность, а потом уже после замечаний РМ и разработчиков корректировать спецификации и повторно согласовывать с заказчиком?
Раз контакт есть, то половина пути уже позади. Объясните разработчику, что стесняться не нужно. Или, как вариант, можно продолжать стесняться, но оценки при этом всё равно давать.Попробуйте такой процесс:
1. Декомпозируете работу на задачи, занимающие (на глаз) полдня — день. Назовём получившийся список Work Breakdown Structure (WBS).
2. Просите разработчика проставить оценки в каждый пункт WBS. Объясните, что именно вы понимаете под оценкой. Исполнители склонны недооценивать задачи, потому что задача — это как бы вызов их профессионализму, и хочется думать, что (на этот раз) всё получится сделать быстро. Но обычно получается так же, как получалось до этого. В общем, это большая тема, но начните с малого, пусть будут хоть какие оценки.
3. Перед вами — WBS с оценками. Решайте сами, какие из её пунктов отдавать в разработку, какие — упростить или изменить. Если задача получилась слишком большой, разложите на части и попросите оценить их.
Касаемо вашего вопроса. В процессе написания спецификации, как мне кажется, трудоёмкость непосредственно не учитывается. Бывает, что неявно понимаешь, что такая-то реализация будет более трудоёмкой, чем иная, при прочих равных, но это частные случаи. Когда же учитывается трудоёмкость? Это зависит от типа проекта, от отношений исполнитель — заказчик.
Например:
а. Перед подписанием Fixed Price контракта делается та самая WBS, по ней оценивается трудоёмкость, закладываются риски, считается общая стоимость. В процессе подписания объём работ фиксируется, и (теоретически) менять его после этого уже нельзя. После подписания делают как получается, бывает, что оценки превышатся раза в полтора — два — три.
б. Time and Material контракт переносит риски на заказчика. Он просто оплачивает часы, которые затратила команда.
в. Fixed Budget подразумевает ограничение по сумме денег. Расставляем приоритеты в WBS и делаем в порядке убывания приоритетов по пунтам, пока не кончатся деньги.
Благодарностей: 1 Цитировать
Спасибо еще раз за ответ!Оценки программист давать может, попробуем с этим поработать.
На реальных проектах, я так понимаю, в основном пункт б) работает?
На реальных проектах, я так понимаю, в основном пункт б) работает?
На реальных проектах что только не работает :) У меня нет статистики по проектам, но я бы грубо оценил Fixed Price и Time and Material как одинаково часто встречающиеся, Fixed Budget — иногда.
Вы должны авторизироваться для ответа в этой теме.
