uhbif19

akka

Пройдите верстку: htmlacademy.ru/ - безумно отличный проект.
JS: https://www.codeschool.com/paths/javascript

Далее уже берите: WP, Joomla! , Drupal и т.п. и изучайте вместе с версткой :)

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

Хочу сразу заметить, что если фрилансер почти не задает вопросов - скорее всего эстимейт будет некорректным. Я согласен с мнением что можно попросить WBS - график работ - разбиение на задачи и подзадачи - таким образом можно увидеть понял ли фрилансер что необходимо делать или просто кинул общий эстимейт. Насчет того соглашается ли заказчик на наши сроки и как часто приведу пример. К нам в руки попал портал на доработку - понятное дело что необходимо добавить буфер времени потому что есть риски что при изменении кода в одной части могут возникнуть баги в другой. Заказчик сказал что по его мнению эстимейт завышен - мы просто в открытую показали почему эстимейт завышен. В итоге заказчик согласился.

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

Могу говорить со стороны веб команды, что причин тут может быть несколько:
1. Нечеткое Техническое задание. Не выяснили все до конца. Бывает так - оговариваете все понятно что необходимо делать, а когда садишься и пишешь код, выходят новые проблемы, которые не были предусмотрены. Поэтому своим разработчикам я говорю, что прежде чем писать эстимейты и говорить что у них нет вопросов, мысленно в голове представить как будет работать каждый модуль - то есть делать оценку позадачно помодульно.
2. Не учли все риски по проекту - например технология оказалась не способна решить проблему,
3. Нет проектного менеджера - где то поплыл эстимейт, за этим никто не следит, соответственно плывут и все сроки. А эстимейты плывут по разному - но главное с чем мы сталкивались в самом начале - не было change request менеджмента. Заказчик говорил а давай еще вот тут чуть поправим а давай еще вот так сделаем - и все это увеличивало объем работ но эстимейт оставался прежним.
4. Банальная лень фрилансера и не умение рассчитать свой рабочий день.

Как проводить оценку сроков?

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

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

Вариант 2. Оценку сроков производит компетентный специалист с вашей стороны. Но такой подход работает только в том случае, если специалист действительно компетентный. Тем не менее, риски всегда есть, и лучше, если оценку сроков проводит фрилансер. Если для вас критична дата, лучше спросить у понравившегося фрилансера, сможет ли он зафиналить проект к указанной дате, и что потребуется от вас, чтобы он смог работать максимально быстро.

Вопрос фрилансерам — часто ли заказчик соглашается на Ваши сроки?

Если заказчик не соглашается с моими сроками, то встает вопрос, согласится ли он с новым бюджетом.

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

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

От фрилансеров хотелось бы узнать наиболее распространенные причины почему так произошло.

Не хватило мотивации.

Повышайте цену. Больше 4 часов эффективных в сутки не реально именно работать в постоянном режиме. В форс-мажоре можно и по 16 часов, но это недели 2 максимум, потом сгорите.

Но посудите сами: кто-то пишет рейт $15 в час, подразумевая что будет получать $2400 в месяц. А вы пишите $45 в час, подразумевая что будете получать $2400 в месяц. Заказчик видит только 2 суммы $15 и $45. Кого он выберет?

А это от ЦА зависит.
Если Вы гонитесь за разовыми клиентами и Ваши многочисленные конкуренты с аналогичными статами пишут 15 против Ваших 45, то таки да, выберут 15уе-шных.
Если Вы гонитесь за длинными клиентами, то есть хороший шанс и со ставкой 45уе в час.

У нас бОльшая часть постоянных заказчиков это те, которые работали с 15-уешными и получив пару раз счет на 4 часа за установку вордпресса на хостинг, перешли к нам на постоянку. Иногда уходят, но всегда возвращаются (у нас демпинговые цены относительно, т.к. не любим искать заказы).

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

Конкретно на собеседовании в Google абсолютно нормально относились к Python для решения задач. Хотя некоторые на С/С++ проще решаются.
В основном смотрят на алгоритм решения, проверку граничных условий, временную сложность (и вашу оценку её).

У нас сделан второй вариант (одна база). Если клиент большой, то под него выделяется отдельный инстанс приложения со своей базой.

Да у них там просто описаны все варианты для любителей всех систем сборки. Simple Bad Tool — просто надстройка над Ivy. Я являюсь ярым противником обоих и предлагаю использовать Maven.
Как бы то ни было, если вы предпочитаете SBT, то репозитории в нем добавляются так:

resolvers += "Sonatype OSS Snapshots" at "https://oss.sonatype.org/content/repositories/snapshots"

Посмотрите Solr. Lucene стала частью проекта Solr. Рекомендую пролистать Apache Solr Cookbook (вот туточки описание книги http://www.packtpub.com/solr-3-1-enterprise-search-server-cookbook/book). Из бесплатного: https://people.apache.org/~hossman/apachecon2008us/ootb/apache-solr-out-of-the-box.pdf

Почему Solr, а не Sphinx: по моему личному субьективному мнению Solr изначально куда более гибок и кросс-платформен за счет Java.

С уважением,

С

Если качество работы устраивает, и вы понимаете, что она стоит в сто раз дороже — скорее всего и студент ошибся (не рассчитал свои силы) и заказчик/менеджер ошибся (поверил в чудеса и халяву). Возможно, стоит подумать о дополнительной оплате, чтобы у студента не опускались руки и не пустели карманы.

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

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

Мораль для себя из этой ситуации:
— вина в такой ситуации ложится на двоих, я+подряд, должен был не давать четких сроков и не давать четкий бюджет. есть минимум, есть максимум.
— заказчик должен понимать, что в разработке- нет понятия четкие сроки и бюджет — никогда. говорят, сделают за месяц. в голове плюсуй еще два. и это, я читаю нормально.
— я работал за процент от прибыли… смех… никогда так не делайте. когда вы после пол года разработки не будете получать з/п, у вас пропадет желание работать, за несуществующую прибыль. деньги мотивируют, как и крути!
— подрядчики, студенты — должны постоянно показывать то что делают. вести task list. только он один показывает, как продвигается проект. а заказчик (менеджер) должен постоянно его контролировать.

и совет студенту: как только понимаешь, что не успеваешь — оповести сразу же заказчка! Есть больша разница, когда ты скажешь за месяц или за день до сдачи, что у тебя проблемы! Как минимум тебе не скажут "А какого х**рена ты раньше молчал!"

А еще очень обидно, когда тебя увольнют, особенно из полюбившегося проекта…

В этом случае явная ошибка того кто дал проект студенту со сроком в 2 недели. Студент виноват, но его можно понять. Что делать:
1. Студента отпустить с миром, денег не давать, раз не справился, портфолио не портить, не его вина.
2. Того кто дал проект студенту с таким сроком и бюджетом наказать.

На самом деле все просто. Нужно понятно пару простых вещей.

1) Деньги не мотивируют. Демотивируют да. Подробнее в этом каменте.
Поэтому то и +- к деньгам да, толку ни какого.

2) Многие программисты находятся в твердой уверенности, что «творят». А творцу нужно вдохновение которое ну ни как не хочет приходить при работе на полный рабочий день. Кроме того творцам не до чужого кода, тем более не до рутины супорта текущего кода. А в реальности творец то и не нужен, нужно зачастую тупо еб**ить, ебо**ть и еще раз е**шить. Есть фронт работ, вот его и нужно делать. И по всей видимости в текущий момент в команде и дизы и копирайтеры как раз из разряда людей который понимают, что работу нужно работать.

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

http://mashable.com/
http://gizmodo.com/