Как убедить программиста не делать все подряд (если сам в IT чайник)?




Главная   Форумы   Общие вопросы и обсуждения   Как убедить программиста не делать все подряд (если сам в IT чайник)?

В теме 5 ответов, и 2 участника, последнее обновление сделано пользователем Аватар (Антон Труханёнок) Антон Труханёнок 9 г, 7 мес. назад.

Показано 6 ответов - от 1 до 6 (всего 6)
  • Автор
    Сообщения
  • 20.02.2015 в 14:39 # 17771
    Аватар (Lena Truhtanova)
    Lena Truhtanova
    Подписчик
    Предистория: я — экономист в строительной компании (образование, соответственно, БГУ экономика и БНТУ стройфак). По совмещению на меня «повесили» функции аналитика: спецификации для программиста 1С при автоматизации ряда функций.

    Мне понравилось очень-очень, теперь я сама на себя эти обязанности «навешиваю», но есть ПРОБЛЕМА: я не программист, вообще не программист, последнее, что делала по программированию — это паскаль в школе….  И я не могу оценить трудоемкость задачи и вообще, можно ли это сделать. Программист сидит в другом городе, видимся редко, общение — скайп, телефон, вьюер и т.д.

    Уже бывало несколько раз, что я описывала задачу, которую с точки зрения логики можно сделать и на схемке все красиво, а на платформе 1С это оказывалось очень трудоемко или опасно. Раньше был программист, который с порога посылал с такими задачками. Если задача была важная и прям очень-очень нужная, я спорила, если нет — значит нет.

    Теперь программист — очень исполнительная милая девушка, берет любую работу, даже то, что вручную сделать было бы быстрее и проще, чем автоматизировать. Конечно, я спрашиваю, сколько это может занять времени и указываю приоритеты, но приоритеты ОЧЕНЬ субъективны. Программист к тому же не склонна спорить, все делает, а потом оказывается, что если бы чуточку изменить требование — все было бы в 100 раз проще, хотя, в идеале, лучше это требование не менять.

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

    з.ы. Если аналитик — бывший программист, вопрос, конечно, не актуален)))).

    Поделиться:

    Цитировать

    24.02.2015 в 11:59 # 17786
    Шанс есть. Чтобы ощущать трудоёмкость задач, делайте декомпозицию до кусочков в несколько дней или мельче. Делайте оценки, потом сравнивайте их с фактически затраченным временем, сохраняйте для истории.

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

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

     

    К слову, мне не нравится слово «спорить» в этом контексте. Здесь уместнее будет «диалог»: разработчик доносит до менеджера цену и риски реализации «фичи», а менеджер уже решает, что делать. «Посылать с порога» звучит как-то брутально. Если сотрудник отказывается делать свою работу, то может ли он сам быть послан туда же? Если коллега отказывается выполнять поставленную задачу, и у вас нет на него влияния, обращайтесь к тем, у кого оно есть, или «эскалируйте» проблему.

    О классификации приоритетов. Можете использовать MoCCoW. Но по сути названия не имеют значения. Назовите приоритеты так, чтобы всем было понятно. Например: «Обязательно» и «Желательно» (часто хватает двух приоритетов).

    Можете использовать «предспецификацию» как черновик требований, без лишних деталей, только то, что нужно для оценки трудоёмкости и реализуемости. Конечно, этот подход используется, часто — в начале проекта или фазы.

    Поделиться:

    Цитировать

    24.02.2015 в 12:27 # 17787
    Аватар (Lena Truhtanova)
    Lena Truhtanova
    Подписчик
    Спасибо за ответ.

    Налаживайте контакт с вашим разработчиком.

    Контакт у нас хороший:) Мне иногда кажется, что именно из-за хороших отношений она стесняется сказать, что работа слишком трудоемкая и что хорошо бы что-то убрать. Или просто не вникает в саму задачу с аналитической точки зрения, это, конечно, и не ее работа. Предыдущий программист сначала сам анализировал сущность задачи, а потом мог четко сказать, что ее реализация неэффективна. Для меня это было очень удобно.

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

    По приоритетам — я пока указываю как часто функция будет использоваться, и для каких нужд: для управленческого учета или регулируется законодательно.

    Тогда еще вопрос о непосредственно работе аналитика в «классическом» варианте. Когда вы собираете требования и пишете спецификацию, вы не учитываете трудоемкость и выполнимость задач? Т.е. задача аналитика «описать как есть» без корректировок на рациональность, а потом уже после замечаний РМ и разработчиков корректировать спецификации и повторно согласовывать с заказчиком?

    Поделиться:

    Цитировать

    25.02.2015 в 16:37 # 17791
    Раз контакт есть, то половина пути уже позади. Объясните разработчику, что стесняться не нужно. Или, как вариант, можно продолжать стесняться, но оценки при этом всё равно давать.

     

    Попробуйте такой процесс:

    1. Декомпозируете работу на задачи, занимающие (на глаз) полдня — день. Назовём получившийся список Work Breakdown Structure (WBS).

    2. Просите разработчика проставить оценки в каждый пункт WBS. Объясните, что именно вы понимаете под оценкой. Исполнители склонны недооценивать задачи, потому что задача — это как бы вызов их профессионализму, и  хочется думать, что (на этот раз) всё получится сделать быстро. Но обычно получается так же, как получалось до этого. В общем, это большая тема, но начните с малого, пусть будут хоть какие оценки.

    3. Перед вами — WBS с оценками. Решайте сами, какие из её пунктов отдавать в разработку, какие — упростить или изменить. Если задача получилась слишком большой, разложите на части и попросите оценить их.

     

    Касаемо вашего вопроса. В процессе написания спецификации, как мне кажется, трудоёмкость непосредственно не учитывается. Бывает, что неявно понимаешь, что такая-то реализация будет более трудоёмкой, чем иная, при прочих равных, но это частные случаи. Когда же учитывается трудоёмкость? Это зависит от типа проекта, от отношений исполнитель — заказчик.

    Например:

    а. Перед подписанием Fixed Price контракта делается та самая WBS, по ней оценивается трудоёмкость, закладываются риски, считается общая стоимость. В процессе подписания объём работ фиксируется, и (теоретически) менять его после этого уже нельзя. После подписания делают как получается, бывает, что оценки превышатся раза в полтора — два — три.

    б. Time and Material контракт переносит риски на заказчика. Он просто оплачивает часы, которые затратила команда.

    в. Fixed Budget подразумевает ограничение по сумме денег. Расставляем приоритеты в WBS и делаем в порядке убывания приоритетов по пунтам, пока не кончатся деньги.

    Поделиться:

    Благодарностей: 1   Цитировать

    26.02.2015 в 08:24 # 17792
    Аватар (Lena Truhtanova)
    Lena Truhtanova
    Подписчик
    Спасибо еще раз за ответ!

    Оценки программист давать может, попробуем с этим поработать.

    На реальных проектах, я так понимаю, в основном пункт б) работает?

    Поделиться:

    Цитировать

    26.02.2015 в 17:16 # 17793

    На реальных проектах, я так понимаю, в основном пункт б) работает?

    На реальных проектах что только не работает :) У меня нет статистики по проектам, но я бы грубо оценил Fixed Price и Time and Material как одинаково часто встречающиеся, Fixed Budget — иногда.

    Поделиться:

    Цитировать

Показано 6 ответов - от 1 до 6 (всего 6)

Вы должны авторизироваться для ответа в этой теме.