Беседа о вашей работе

[axtalk]

Цитата:

Сообщение от klimova_m

На самом деле бывают и первые истории, и вторые, просто разница не такая большая в деньгах. Особенно если посчитать, чем заплачено за это благополучие.

Кому как, но по мне так это просто другая жизнь, когда доход семьи в 3 раза отличается. И дело не только в этом статичном доходе, а в постоянном нескончаемом росте и движении. А заплачено трудом, в основном, и в том, и в другом случае.

Цитата:

Сообщение от klimova_m

Знаю, что ступаю на зыбкую почву сейчас, но это как всем малозарабатывающим не в Москве советовать ехать в столицу. Да, зарплата вырастет в пару раз, но вырастет и стоимость квартиры, и минус два часа в день на дорогу, и экология отвратительная со всеми вытекающими. Не все хотят жить в огромном городе с диким ритмом.

Да сейчас все удаленно можно делать касательно консультантов и программистов MS Dynamics AX. Не надо уже никуда ездить. Напомнило тему Недостойно удаленно

Цитата:

Сообщение от klimova_m

Каждый выбирает для себя.

Это точно!

[klimova_m]

Последняя мысль про вторую историю: дешево, качественно, быстро - чем-то придется все же поступиться, а это уже рыск.

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

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

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

[axtalk]

Многие работают с т.н. почасовой оплатой, но эта почасовая оплата бывает очень разная в мелочах, которые значительно меняют весь процесс работы в целом.

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

Предварительная оценка может использоваться для:
1. Планирования
2. Фиксации стоимости работ

Возможен вариант, когда в процессе используется предварительная оценка для планирования, но оплата происходит по фактическим трудозатратам. Это нормальный вариант – тут нет никакой «ловушки».

«Ловушка» возникает, когда перемешивают:
1. Работу с предварительной оценкой, которая используется как фиксация стоимости работ
2. С оплатой по фактическим трудозатратам.

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

По сути, получается просто работа по фактическим трудозатратам. Зачем тогда предварительная фиксация стоимости работ? А чтобы была минимальной эта оценка. И это не выгодно исполнителю, а выгодно заказчику.

Когда мы смешиваем предварительную оценку и фактические трудозатраты, мы искажаем суть предварительной оценки как фиксации стоимости работ.

Что же такое предварительная оценка задачи:
1. Это стоимость задачи в часах
2. Это некое усредненное время, за которое можно выполнить задачу условному среднему специалисту
3. Оценка учитывает некие известные условия (например, существующие фреймворки или типовые задачи)
4. Оценка учитывает среднее количество средних рисков и трудностей, которые с какой-то долей вероятности могут возникнуть в процессе выполнения задачи
5. Оценка – это НЕ минимальное время, за которое возможно выполнить задачу условному суперспециалисту, который все знает
6. Оценка – это НЕ фактические трудозатраты
7. Оценка не означает, что в процессе работы она не может быть пересмотрена в результате появления новой информации и изменении первоначальной задачи (это к тому, что исполнитель тоже застрахован от появления неоплачиваемых часов)
8. Это те согласованные часы, за которые исполнитель может не отчитываться, если задача выполнена – не надо лишний раз обосновывать на что потрачено время
9. Это в 99% случаев время, достаточное для комфортного выполнения задачи без гонки, нервов и суматохи

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

Работайте либо по предварительной оценке, либо по фактическим трудозатратам – не смешивайте в одной задаче. Это не выгодно исполнителю.

Подкрепим примером. Нанимаем землекопателя (живой экскаватор). Задача: нужно выкопать яму/траншею объемом 2 куб. метра. Известно, что в среднем темпе работы средний человек выкапывает в «средней» почве за 1 день (9 часов) 3 кубических метра – это нормально. Условно средний норматив 1 кубический метр за 3 часа.

Вариант 1: договариваемся по предварительной оценке: 2 куб. метра за 6 часов = (при условии 1 час стоит 1 000 рублей) 6 000 рублей – это стоимость работы.
Возможные исходы:
1. Почва рыхлая, корней и камней почти нет, ваша лопата острая, есть и другие инструменты, которые помогают в работе, вы опытный и сильный, работали усердно, сделали за 3 часа, заработали 6 000.
2. Почва не очень, много корней и камней – это вы частично учли в рисках. Другие инструменты и ваш опыт помогают с ними справляться. Вы сильный и опытный, работали усердно, в самом плохом варианте сделали за 5,5 часа, заработали 6 000.
3. Наткнулись на плиту. Надо решать выкапывать плиту или менять расположение. Вам оплатили по фактическим затратам время, которое было потрачено. Дальше это уже другая задача. Это и есть страховка исполнителя.

Вариант 2: договариваемся по предварительной оценке, но не совсем. «Если корней и камней не будет», - говорит нам ушлый заказчик, - «то, скорее всего, можно всё выкопать и за 4 часа. А если что, то накинем за сложность и посмотрим, что там по факту».
Возможные исходы (при аналогичных условиях):
1. Сделали за 4 часа (так как не было стимула делать быстрее. Совсем клинический случай, когда очень старались и сделали за 3, мы не рассматриваем.), заработали 4 000.
2. Скорее всего сделали за 4,5-5 (так как надо было в оценку уложиться, но не уложились) и заработали в лучшем случае 4 500 - 5 000.
3. Наткнулись на плиту – это форс-мажор, оплата по факту, другая задача.

Видно, что первый вариант выгоднее чем второй?

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

Ну и рассмотрим еще 3-ий вариант, когда договорились об оплате по фактическим трудозатратам. Возможные исходы (при аналогичных условиях):
1. Напевая песни с сигареткой в зубах и пивом в руке, сделали за 6 часов, заработали 6 000.
2. Без пива и с недолгими перекурами сделали за 7 часов, заработали 7 000.
3. Наткнулись на плиту позже, чем в первых двух вариантах, заработали больше, чем в первых двух вариантах.

Называйте вещи своими именами и не обманывайте себя.
Кто ищет правильную работу – пишите на axtalkget@gmail.com

[sukhanchik]

Цитата:

Сообщение от axtalk

Подкрепим примером. Нанимаем землекопателя (живой экскаватор). Задача: нужно выкопать яму/траншею объемом 2 куб. метра. Известно, что в среднем темпе работы средний человек выкапывает в «средней» почве за 1 день (9 часов) 3 кубических метра – это нормально. Условно средний норматив 1 кубический метр за 3 часа.

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

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

Поэтому, чтобы "не обмануться" - задачу не оценивают по предварительной оценке, а оценивают глубоко и серьезно. Но время, потраченное на оценку - включают в стоимость задачи. Мелкие задачи можно оценить и не обмануться, а уже для крупных - процедура оценки и согласования должна входить в стоимость задачи.
В консалтинговых компаниях этот этап называется "Дизайн проекта".
Другое дело, что можно глубоко проработать задачу, но потом заказчик возьмет и ее не станет делать / отдаст другому разработчику. В этом случае нужно просто договориться с заказчиком о схеме работы. Либо крупные задачи не брать, либо их делать не за фиксированную сумму, либо "коней на переправе не меняют". Один из вариантов - это выделение проработки задачи в отдельную задачу, хотя тут весьма сложно будет оценить полноту результата задачи

[twilight]

Цитата:

Сообщение от sukhanchik

В случае программирования тут не так. "План местности" доступен всем и каждый может с ним ознакомиться (=залезть в код). Опытность специалиста как раз и заключается в знании, где лежат "плиты" и умении прокопать с минимальными затратами и максимальной эффективностью для заказчика.

В современных условиях постоянно меняется и место, где копать (новые требования). Да и сами плиты возникают и исчезают динамически в процессы работы Мало того, появляются новые типы лопат и типы плит. Поэтому заранее дать точную оценку способен только разработчик, который буквально вчера копал в этом самом месте

[sukhanchik]

Цитата:

Сообщение от twilight

В современных условиях постоянно меняется и место, где копать (новые требования). Да и сами плиты возникают и исчезают динамически в процессы работы Мало того, появляются новые типы лопат и типы плит. Поэтому заранее дать точную оценку способен только разработчик, который буквально вчера копал в этом самом месте

))))))))
Ну да.... Это я ещё в воспоминаниях о версиях AX2012 и ниже... Но оценить процент недовыполненных работ все равно не получится также как у копателя.

[axm2017]

Цитата:

Сообщение от sukhanchik

...
Поэтому, чтобы "не обмануться" - задачу не оценивают по предварительной оценке, а оценивают глубоко и серьезно. ..

Что не всегда скажем так помогает.

Традиционно оценка от n часов (в каких то конторах от 40, в каких то выше) означает высокие риски что может и не повезти.

Собственно по этой причине и родился agile в том числе:
я могу конечно оценить путь до Владивостока по земле в n дней однако в реальности +- спрогнозировать точно получается лишь путь от себя и до той горы так как вижу дорогу до горы + чувствую погоду и прочие вещи.

[sukhanchik]

Цитата:

Сообщение от axm2017

Что не всегда скажем так помогает.

Традиционно оценка от n часов (в каких то конторах от 40, в каких то выше) означает высокие риски что может и не повезти.

Собственно по этой причине и родился agile в том числе:
я могу конечно оценить путь до Владивостока по земле в n дней однако в реальности +- спрогнозировать точно получается лишь путь от себя и до той горы так как вижу дорогу до горы + чувствую погоду и прочие вещи.

Ну тут главное не путать понятия "сроки" и "трудозатраты". Сроки действительно планируются до горы, а дальше с учетом погоды и прочих вещей (собственно - любая методология agile, scrum и т.д. ориентирована в первую очередь на планирование сроков). Но от того, что день пережидаешь под дождём где-то в укрытии - трудозатраты не меняются.
Для себя я заметил закономерность - если при постановке задачи в голове уже есть чёткое понимание конкретных строк кода - то оценка не должна превысить 8 часов. А если чёткого понимания нет - значит будет больше 8 часов.

Оценка в 40 часов - небольшая, если в ней сидит 8 часов проработки задачи. Потому что оставшееся время можно поделить непосредственно на разработку, тестирование и написание инструкции / обучении заказчика использованию модификации. В итоге получается, что непосредственно на разработку остается часов 16-20, а это вполне посильный горизонт оценки при правильной проработке задачи.

Ну а если задача действительно большая - то надо дробить. И время на дробление должно входить во время проработки задачи.