Чтож, в первой части я долго и упорно лил из пустого в порожнее, преследуя лишь одну цель — признать, что в провалах проектов по стоимости и срокам виноваты мы, мы и только мы. Не существует мифических дядь Вась, повинных во всех наших бедах, не заказчик выносит нам своими требованиями и сменой приоритетов — это все мы, родимые, учиняем, потом благополучно взращиваем и оберегаем от внешнего воздействия. Так что если вы с этим спорить не будете, то айда под кат, посмотрим что у нас дальше на повестке дня.
Но для начала, товарисчи, я бы хотел прокомментировать пост, появившийся на хабре сегодня же. Прочитав его внимательно и найдя достаточно интересным, я зацепился глазами вот за эту фразу:
Теперь о главном, о оценке заказа. На форумах и в комментах часто пролетает такой критерий оценки стоимости:
«Прикидываешь стоимость комплектухи, добавляешь к этому стоимость часа своей работы, помноженный на количество затраченных часов. Как то так».
Господа, выкиньте из головы это дерьмо! Вы больше не наемные сотрудники, чтобы считать часы своей работы. Час вашей работы это лишь себестоимость, по этой формуле будете считать труд наемных сотрудников, когда они у вас появятся. А работать надо в прибыль.
По долгу службы (кхе-кхе :) ) мне пришлось столкнуться, и достаточно плотно, с разработкой электроники. Все там именно так, как описано в посте, ведь именно на том сайте мне предложили выполнить работу, которую в итоге я делал сам за 5 дней, за 40 т.р… При сроках в двое меньших :)
Так вот. До тех пор, пока рынок не перенасыщен, главную скрипку там играет исполнитель. Он может совершенно спокойно выковыривать цену из носу, может заковыристо покакать и попытаться прочитать в загогулине сумму проекта, может в конце концов пробежаться пальцами по NumPad-у и выдать это за стоимость работ. Не вопрос.
К сожалению, я не считаю данный подход верным, и вот почему. Работа — она и в африке работа. Фриланс хорош тем, что у человека нет каких либо стандартно-офисных обязательств перед работодателем, он может совершенно спокойно работать из другой точки мира, а так же самостоятельно определять время, которое он тратит на работу. Работу, еще раз подчеркну. Наивно считать, что фриланс — это фриланс. Ну фриланс. Короче фриланс, ну ты понял, да? Это ра-бо-та. Со всеми обязательствами, с зарплатой, которую ты получаешь, а так же ответственностью. И определять заказчика по тому, какую пользу приносит это ему, и отсюда выдвигать ценник можно только до тех пор, пока предложений больше, чем исполнителей.
Ну или до тех пор, пока работодатель не поймет, что отдать на фриланс сайт и железку — почти одно и то же. Именно тогда и придет Кабзон подобного рода отношению к оценке.
Хочу отдельно отметить — я не утверждаю, что стоимость работ в посте завышена, наоборот — она в некоторых местах недостаточно высока. Я не против ценников, я против способа.
Ну а что до программирования, то с одной стороны приходится при проектировании решений, в особенности спец-проектов, решать нетривиальный пул задач, оценить влияние на компанию для которых сложно, а с другой — гораздо больше исполнителей, работающих по нормальной схеме. И если среди предложений на разработку 200 т.р. ± 50 т.р. встретится предложение на два ляма, появившееся просто потому что фрилансер не поленился пробить человека в «интернетах», и узнал чем тот промышляет — вероятность того, что подобный кост будет тут же засунут в игнор и о человеке больше никто не вспомнит, не просто высока — так и будет. Так что учитесь сразу работать правильно.
Ну хватит лирики, приступим к практике.
Давайте поговорим о старте работ, а точнее о том, как мы к ней приступаем.
В качестве оффтопа — тут опять будет очень много повторения одного и того же под разным соусом. Я не хочу, чтобы эта мысль была лишь парой строк в тексте. При борьбе за нормально завершенные проекты важна каждая деталь, и выполнение всех пунктов.
Варианты старта
Хотел было рассказать о теории, да пока что рановато. Давайте лучше с вами пробежимся по практике :)
Вариант 1. Да времени то еще...
Именно так рассуждаем мы, когда откладываем старт проекта на неопределенный срок. Причин тому может быть уйма — начиная от завершения текущего проекта и заканчивая банальной ленью. И если в последнем случае совет тривиален — начинайте сразу, то на первом варианте хотелось бы остановиться поподробней. Как правило, фрилансеры-одиночки или маленькие студии не ждут завершения текущего проекта, и начинают искать новый. Это и понятно — простаивать, если только не планируешь отпуск (о господи! отпуск! хочу в отпуск!), не хочется никому. А для поиска проекта требуется время. Бывает и обратная ситуация — по портфолио к нам стучится человек с интересной работой, которую хочется выполнить, а отказать ему — значит с большой долей вероятности ее лишиться.
Кроме этого, не забываем, зачем мы вообще читаем эту кучу текста. Проекты НЕ завершаются вовремя. Соответственно, запланировав на окончание проекта, к примеру, 2 недели, и увеличив на этот срок время для нового клиента, мы, с большой долей вероятности, не закончим предыдущие работы через 2 недели. Это приводит к тому, что задержка накапливается, оставляя на реализацию нового проекта время, гораздо меньшее того, на которое мы рассчитывали в начале.
Что же делать — возникает резонный вопрос. Отказываться от проекта? Нет, так дело не пойдет. Значит, нужно каким то образом вычленить из текущего проекта его реальное состояние. Не то, которое мы считаем за реальное, а действительно реальное. Как? Я предлагаю ответить на данный вопрос читателям поста. Это вовсе не значит, что я ща вот так брошу незаконченную мысль и сделаю «типа красивый реверанс из патовой ситуации». Просто куча людей, читающих эти строки, сталкивалась с подобными проблемами, и наверняка, подумав, они могли бы указать на маркеры, которые соответствуют тому или иному состоянию проекта.
Со своей же стороны вставлю несколько точек:
Проект не завершен, брать другой не стоит
- На текущий момент вы не уверены, что архитектура проекта верна. Желание переписать проект возникает, как правило, раза три за время работы, даже если вся архитектура спланирована идеально. Это просто свойство нашей программистской души, и от этого никуда не деться. Проявляется оно по разному, у кого в виде «перепишу все с нуля», а у кого — «да что тут класс этот, 200 строк всего, быстренько его отрефракторить, и дальше писать».
- Срок, когда вы должны выйти на тестирование, больше 5 дней. Как правило, через 5 дней этого не случится, сколь сильно бы мы ни были уверены в обратном.
Проект в непонятной стадии, лучше притормозить с ответом и получить дополнительные сведения
- Вы ожидаете комментарий заказчика. Наличие возможности появления нового проекта — самый сильный стимул, чтобы получить его и оценить фронт доработок.
- Финальная версия имеет блуждающие баги. Краш, если он стабильно воспроизводится и прекрасно локализуется, достаточно просто исправить. В случае же, когда ошибка возникает неизвестно когда и непонятно почему, спланировать время на отладку невозможно. Бросьте все силы на локализацию, чтобы понять — это неверное использование какого то простого модуля, или придется переписать пол-проекта.
Можно соглашаться на следующую работу
- проект ожидает финального одобрения. Смело беремся, если ТЗ выполнено на 100%. Все доработки можно смело выкатывать как дополнительные работы, и попросить подождать заказчика вполне себе можно и нужно
- проект имеет финальный список багов, каждый из которых понятен. Кстати, под понятностью я имею ввиду кристальную ясность, откуда что и как получается, а не «эй, да это же наверное тот класс! херня, 5 минут работы»
Вариант второй. Вперед! За родину! За Сталина!
Второй вариант, при котором проект так же страдает, и который встречается столь же часто, как и первый — тут же приступить к программированию. Да, да, да и еще раз да! Новый проект! Свежие идеи! Крутая задача! Ура!
Чтож, для таких людей есть одно простое правило — не садитесь делать проект раньше, чем пройдет 5% от общего времени на проект. Не заложили это время в сроки — ваша проблема. Руки чешутся? Займите их делом. Не тем самым, а нужным для блага проектом делом. Да нет же! Не этим!
Берем ручку/открываем Visio/открываем еще хрен знает что, и рисуем. Рисуем структурную схему. Сначала простейшую. Вот у нас клиент, вот сервер. А вот еще клиент. Если, конечно, приложение — клиент-сервер, но и в любом другом можно найти несколько самых крупных блоков. Разбейте потом на более мелкие. подумайте как оно будет работать. Представьте уже готовое приложение.
Есть чЁ?...
План. Который проекта.
Сегодня я дам несколько рекомендаций относительно того, как выполнять план. Они, по большому счету, справедливы для многих техник управления проектами. В следующей же статье я остановлюсь на планировании проекта, которое мне действительно помогло, и которое я буду естественно пиарить, как эффективное и вообще просто чудесное.
Когда следует составлять план проекта? Тогда, когда проект длительностью более 3-4 недель. Не стоит выполнять серьезные работы по планированию для работы на неделю, и не стоит пренебрегать планом для крупного проекта. По сути, отсутствие плана есть прямая дорога к анархии и бесконтрольному развитию проекта. Все еще надеетесь, что оно само выплывет. Огорчу. Не выплывет.
План не должен содержать излишней детальности, с одной стороны всего не учтешь, с другой — понадобится отдельный манагер для поддержания этого счастья в актуальном состоянии. Не надо писать в задачах «написать метод создания пользователя», а следом — «написать метод удаления пользователя». Это напоминает дневник школьника — третьеклашки. Только в этом возрасте можно уделять столько времени мелочам.
План не должен быть излишне коротким. «Написать клиент», «написать сервер», «сдача проекта» — охерительный план, если вы ставите целью написать план ради его написания.
Как показала практика — минимальным для самого простого проекта является план из 10-15 пунктов, но при написании даже самого сложного плана я старался не переваливать за 200 пунктов. После чего это уже не план — это война и мир какая то.
Составив план, откиньтесь на кресло и закройте на 5 минут глаза.
С новым проектом.
Автор: dtcDev
