Pull to refresh
  • by relevance
  • by date
  • by rating

Как удачно расчитать цену и время проектов во фрилансе

Freelance
Одна из самых больших проблем начинающих фрилансеров — оценка стоимости задания.

На самом деле — оценка стоимости проектов — очень не простой момент и очень важно научится правильно оценивать стоимость проекта, что предлагается.

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

Так как же правильно оценить проект?

Читать дальше →
Total votes 36: ↑32 and ↓4 +28
Views 4.4K
Comments 32

Чего стоит смена интерфейса?

Website development *
Заказчик хочет изменить дизайн. Допустим, даже уже готова вёрстка. Сколько стоит её натянуть? Ну, по столько-то часов на страницу, и накинем ещё по столько то в уме на риски…

— А что там делать? Всё ведь уже готово! Всего то, вёрстку натянуть — Знакомые слова?
А вот ещё одна фраза, модная среди некоторых «руководителей-теоретиков»:
— Смена дизайна, это не более 30% времени всего проекта!

Вот только почему практика расходится с теорией?

А что вы обычно отвечаете? Я обычно говорю:
— Эмм… Ну… Ведь неизвестно, что именно изменилось, возможно, это затронет не только шаблоны.

Только что-то надоело оправдываться. А давайте попробуем разобраться.
Читать дальше →
Total votes 77: ↑66 and ↓11 +55
Views 1.7K
Comments 54

Очередная выстраданная истина

Lumber room
Программисты постоянно срывают сроки не потому, что медленно работают, а потому, что изначально не могут верно оценить срок. Они свято верят в то, что смогут в определенный момент поднажать и сделать больше чем обычно, и никаких непредвиденных проблем при этом не возникнет.
Total votes 34: ↑17 and ↓17 0
Views 242
Comments 19

Два протокола управления проектами

Project management *
Доброго времени суток.

Я пришел в управление проектами из программирования. То есть, нет так давно, я еще писал код и мне это очень нравилось. Меня мало беспокоили волнения, происходящие где-то на верху — «у менеджеров». Все поменялось в 2004, когда меня назначили тим лидом.

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

Тогда я начал задумываться о причинах такой ситуации, начал читать посты и книги по менеджменту. Как программист, находящийся под впечатлением революционных архитектурных решений — таких, как MVC и паттерны Фоулера, я полагал, что есть *техническое* решение наших проблем с менеджментом — нужно его только отыскать и применить.

Следующие несколько лет я искал *супер фреймворк* для управления проектами. Но только недавно понял, что его нет и быть не может. Проблема заключается в том, что в разработке ПО одновременно используются 2 конфликтующих протокола общения между участниками Процесса.

Сейчас я расскажу о моем текущем видении проблемы, а также опишу одну из возможных стратегий совместного использования этих двух протоколов.
Читать дальше →
Total votes 84: ↑77 and ↓7 +70
Views 2.8K
Comments 39

5 причин отказаться от оценок

Taucraft Limited corporate blog
В нашей компании мы не оцениваем работу. Ни в часах, ни в поинтах, ни в зеленых крокодилах. Совсем не оцениваем. Если вы давно хотели отказаться от оценок, но не знали, почему, вот вам пять причин.

1. Вы не будете тратить время на оценки


Оценки занимают время. Даже если вы оцениваете в абстрактных поинтах, играя в покер, все равно тратится прилично времени. А что, если вы хотите улучшить точность оценок? Тогда вы собираете данные, анализируете данные и обсуждаете результаты анализа. Все это тоже занимает прилично времени. Но подумайте, вам на самом деле нужны оценки? Часто это waste. Лучше потратить время на что-то действительно полезное для продукта.
узнать остальные причины
Total votes 109: ↑80 and ↓29 +51
Views 4.7K
Comments 213

Улучшение собственной эффективности: Yaware

Self Promo
Привет, %хабраюзер%!

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

Многие умеют правильно мотивировать себя к работе и не давать халявить, но, даже учитывая это, как можно увеличить собственную производительность? Под катом немного про систему учета рабочего времени и улучшения эффективности Yaware.
Читать дальше →
Total votes 14: ↑7 and ↓7 0
Views 2.2K
Comments 25

Как две недели?!

Инфопульс Украина corporate blog Website development *
Как это вам надо две недели на эту задачу? Что, правда? Вот на эту элементарную формочку с тремя полями и двумя кнопками? Две недели? Да вы надо мной издеваетесь, наверное! Давайте разбираться.

Что? Нужна ли валидация данных при вводе? Ну, конечно, нужна! И вообще, вот это поле лучше разбить на два, так понятнее. А вот в это добавить маску. А вот это — заменить на выпадающий список. Где брать варианты для этого списка? В базе на сервере, конечно. Как это их там нет? А, ну да, это же в другом проекте они у нас были… Ну, значит надо добавить. Взять там и добавить сюда. Сейчас я дам вам контакт разработчика того проекта — обсудите с ним. Он, правда, у нас уже не работает, но я думаю, вполне можно спросить что и как — он расскажет, скорее всего.

Мы всё обсудили? Нет? Что ещё?
Читать дальше →
Total votes 334: ↑288 and ↓46 +242
Views 104K
Comments 82

Программирование, быстрое и медленное: разработчики и психология самоуверенности

Self Promo
Translation
Сегодня я собираюсь рассказать о том, что происходит в головах разработчиков программ, в тот момент, когда они делают предварительные расчеты; о том, почему им так сложно зафиксировать все задумки в своей голове; а также о том, как лично я разрешил для себя эту ситуацию, узнал, как жить и писать ПО (для счастливых владельцев бизнеса), но, уверен, мои собственные оценки трудоемкости ненадежны как никогда.

Но сначала история…

Это было <вставьте период времени, который не будет делать меня нелепо старым> в то время, когда я был молодым разработчиком (1). В колледже я был лучшим на занятиях по программированию, будучи младшим разработчиком, я мог взломать код и решить любую поставленную передо мной задачу быстрее, чем кто-либо ожидал. За выходные я мог изучить новый язык и продуктивно на нем работать (или, по крайней мере, мне так тогда казалось).

Таким образом, как и должно было произойти, у меня появился свой собственный проект. Менеджер по работе с крупными клиентами объяснил мне в общих чертах, чего хочет клиент, мы это обсудили, и я сказал: «На эту работу уйдет 3 недели.» «Хорошо», — ответил он. И так я приступил к программированию.

Как вы думаете, сколько времени у меня ушло на этот проект? Четыре недели? Может быть пять?

Мм, вообще-то: три месяца.

У меня остались четкие воспоминания о том времени – мое представление о себе было тесно связано с ощущением, что я — «хороший программист», в чем я сильно разочаровался. Я потерял сон, у меня случались небольшие приступы паники. И этому Не Было Конца. Я помню, что у меня сосало под ложечкой при разговоре с тем менеджером, я снова и снова объяснял, что у меня до сих пор нет ничего, что можно ему показать.

В один из таких черных периодов я решил, что Больше Никогда Не Буду Совершать Подобных Ошибок.

К сожалению, в ходе своей карьеры, я уяснил нечто очень тяжелое: я постоянно совершаю подобные ошибки.
Читать дальше →
Total votes 62: ↑51 and ↓11 +40
Views 49K
Comments 36

Доказательное планирование

Programming *
Translation
Примечание переводчика: оригинальная статья была написана в 2007-м году, однако, на мой взгляд, полностью сохраняет актуальность и сегодня.

Разработчики программного обеспечения не любят составлять план работ. Обычно пытаются вовсе от него отказаться. «Закончу, когда закончу!», — говорят они, ожидая, что этот смелый и веселый поступок вызовет одобрение у босса, а о планировании будет успешно забыто.

Большая часть расписаний, с которыми вы встретитесь, будет представлять из себя бездушные отписки. Совершенно забытые, они хранятся в каком-нибудь общем каталоге. После выпуска продукта с опозданием на пару лет странный парень, в чьем офисе, говорят, видели картотеку, принесет на обсуждение причин провала старую распечатку, которую все засмеют. «Только гляньте! Мы запланировали две недели, на переписывание системы с нуля на Ruby!»
Читать дальше →
Total votes 59: ↑54 and ↓5 +49
Views 38K
Comments 23

Разработка ПО: факты против мифов

Programming *
Мифы – это попытки осмысления картины окружающего мира, присущие первобытной культуре.

Материальное производство (обработка объектов физического мира) насчитывает десятки тысяч лет истории. Оно прошло путь от каменных пещер до современных небоскребов, от сигнальных костров до мобильной связи, от навигации по звездам до навигации по космическим спутникам. На этом пути был накоплен колоссальный объем знаний естественных наук: математики, физики, химии, географии, геологии, биологии и проч.

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

За короткую историю в отрасли сложилось большое количество мифов, суеверий и религиозных заблуждения. Эти мифы, суеверия и заблуждения, порой очень похожи на правду. Они получили широкое распространение и пагубно влияют на руководителей, которые никогда сами профессионально не разрабатывали ПО. Следствием этого является применение неадекватных методов и подходов в управлении программистами, что гарантированно приводит проект к провалу.

Вот наиболее распространенные мифы и факты, которые их опровергают.
Читать дальше →
Total votes 150: ↑135 and ↓15 +120
Views 68K
Comments 124

Почему так сложно оценивать сроки разработки (плюс задача для разработчиков)

Website development *
image
Эм, а можно немного подвинуть розовую область?

В повседневной жизни мы постоянно пытаемся всё оценивать: сколько мне нужно времени, чтобы добраться на работу? Сколько денег я трачу в месяц? Достаточно ли у меня еды для предстоящей большой вечеринки? И так далее…

Кажется, постоянная оценка всего вокруг — это часть нашей жизни. Так что не удивительно обнаружить то же самое и в разработке ПО.
Читать дальше →
Total votes 44: ↑21 and ↓23 -2
Views 23K
Comments 34

Как оценивать задачи без помощи разработчиков?

Project management *Product Management *
Несмотря на то, что в нашей небольшой компании никто не обращает внимания на сроки (заказчику это не важно), я время от времени сталкиваюсь с необходимостью оценить сколько времени займёт разработка той или иной функциональности или набора задач. Помимо оценки методами «на глаз» и «при помощи разработчиков», которые часто дают большую погрешность, я пользуюсь ещё одним несложным подходом. Подход заключается в измерении среднего времени выполнения одной задачи в прошлом.
Читать дальше →
Total votes 14: ↑12 and ↓2 +10
Views 7.5K
Comments 8

Как дать адекватную оценку времени, когда неопределённость бьёт по башке

Development Management *Agile *Personnel Management *
Большинство людей не умеют адекватно оценивать сроки выполнения задач. Ой как это заставляет порой понервничать… Тут и «дэдлайн подкрадывается незаметно». И перестраховка в 500% на всякий случай (все равно не хватает). И отжимание «заведомо раздутых сроков», чтобы исполнитель пообещал чего-то более приемлемого. И невнятные бормотания вместо конкретных цифр.

image

В этой статье собраны и структурированы принципы и методы, с помощью которых можно научить себя и других давать адекватные оценки. В начале — общие принципы и чуть-чуть математики. В конце — конкретика для студий.
Читать дальше →
Total votes 81: ↑68 and ↓13 +55
Views 73K
Comments 24

Оценка стоимости ПО: Дэн Гэлорат и SEER-SEM

Development Management *Project management *Agile *


Дэниэль Д. Гэлорат — президент и исполнительный директор Galorath Incorporated и главный разработчик SEER-SEM, программного продукта по алгоритмическому управлению проектами.

Он считается экспертом в области оценки программного обеспечения и автор книги «Программное обеспечение, оценка и риск-менеджмент» («Software Sizing, Estimation, and Risk Management»).

«Книга помогает определить лучший способ инвестировать в улучшение производительности программного обеспечения.»
— Берри Боэм, автор спиральной модели и COCOMO
Читать дальше →
Total votes 7: ↑5 and ↓2 +3
Views 5.3K
Comments 0

Как оценивать большие задачи

Mindbox corporate blog Agile *
Существует множество способов оценить пользовательские истории. Мы используем собственную методологию, чтобы оценить и проработать задачи перед тем, как писать код. Как мы до этого дошли и почему наш подход лучше, чем Planing Poker, читайте под катом.

image
Читать дальше →
Total votes 21: ↑21 and ↓0 +21
Views 22K
Comments 19

Почему приоритизация по трудозатратам и ценности не работает

Kolesa Group corporate blog Development Management *Project management *Start-up development Product Management *
Translation

И почему всё же стоит использовать её


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


Оценка трудозатрат на разработку и ценности (отдачи от трудозатрат) — главный элемент приоритизации в продуктового бэклога: это простой понятный подход, а потому очень популярный. У вас наверняка есть 2 такие колонки в продуктовом бэклоге (и даже если нет, то стоит их добавить):



Читать дальше →
Total votes 15: ↑14 and ↓1 +13
Views 6.8K
Comments 18

Цена изменений: во сколько на самом деле обойдется переработка кода

Wirex corporate blog Programming *Development Management *Statistics in IT
Translation
Автор этого материала делится способом оценки времени, которое будет затрачено на переписывание уже внедренного проекта.


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

Модель оценки объема работ


Вы можете свести в один список все фичи своего приложения, а после оценить этапы и приблизительное время их переработки. Большинство именно так и поступает перед тем, как приступить к работе. Но почему тогда на практике выходит, что подобные проекты занимают в 4, 8 или даже 10 раз больше времени, чем разработчики заложили на старте?

Читайте также
Публикация о временных затратах на написание программного кода, которая пригодится при оценке объема работ: «Правило 10:1 в программировании и писательстве»


Есть три ключевых фактора, которые существенно растягивают процесс. И обычно при оценке затрат их игнорируют. Речь идет о:

  1. необходимости наверстать разницу между уровнями текущего и нового приложений,
  2. объеме непредусмотренных изменений,
  3. улучшениях, которые придется сделать, чтобы пользователи захотели перейти на новое приложение.



Сокращение разницы


Первый фактор — новому приложению необходимо догнать текущее.
Читать дальше →
Total votes 17: ↑16 and ↓1 +15
Views 6.5K
Comments 3

Простые практики прогнозирования временных затрат

Development Management *Personnel Management *

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


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

Читать дальше →
Total votes 18: ↑15 and ↓3 +12
Views 5.8K
Comments 28

Оценка затрат на разработку через TDD

Development Management *

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


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

Читать дальше →
Total votes 16: ↑14 and ↓2 +12
Views 4.5K
Comments 1

Об оценке и управлении разработкой программных продуктов

Programming *Development Management *Project management *
image

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

Между тем, этот навык необходим любому программисту ежедневно. Работы всегда больше, чем можно выполнить. Оценка помогает правильно расставить приоритеты, а от каких-то задач вообще отказаться. Не говоря уже о таких бытовых вопросах как бюджетирование и планирование. Неверные оценки, наоборот, создают кучу проблем: заниженные — конфликтные ситуации, переработки и дыры в бюджетах, завышенные — отмены проектов или поиски других исполнителей.

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

В статье я расскажу о том, как менялось мое отношение к оценке задач и как сейчас оцениваются проекты в нашей компании. А начну я с того, как оценивать не надо. Если про то как «не надо» вы уже знаете, переходите сразу ко второй части статьи.
Читать дальше →
Total votes 12: ↑12 and ↓0 +12
Views 9.2K
Comments 3
1