Wiki Category: Дао

просто за-бали уже до чертиков со своими высерами про цеховых рабочих

Утянул у

Gennady Dogaev full-stack web developer (freelance)

ну вот жеж, любое сравнение с обычной работой на потоке тебя подрывает неслабо, судя по прошлому комменту)

Я прямо сейчас кое-что «собираю из готового», и прямо-таки матом не ругаюсь, а разговариваю, поэтому да — меня дико бомбит от этих высеров про цеховых рабочих.

Чисто для примера сборки из всего готового:

  • Разработчики фреймворка вообще молодцы и создали классную вещь, но они клали на анимацию при перереходе между страницами (а без анимации SPA по ощущениям таки похуже, чем с ней, даже статья вот есть почему)
  • Разработчик плагина для той самой анимации тоже молодец и проделал огромнейшую работу, но не учел особенности при подгрузке данных с сервера и не под каждую верстку оно одинаково хорошо работает
  • Ну и разработчики UI-фреймворка тоже конечно молодцы, но они клали на всё вышеописаное

И вот оно по отдельности вообще все офигенное и классное и осталось только все вместе собрать в свой сраный примитивный CRUD, но не тут-то было — всё вместе оно начинает работать криво и ты не нагуглишь почему, потому что до тебя никто не использовал это с тем же UI-фреймворком и большинству не нужна была отдельная анимация для загрузки данных. И начинается самое интересное — понять что не так с твоим сетапом что у тебя оно не работает как ты хочешь, и либо найти воркэраунд методом тыка, либо погрузиться в большое количество кода незнакомых тебе людей чтобы понять до конца как оно устроено и в чем реальная причина твоих бед. Цеховой рабочий, *** !

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

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

gty_dog_cat_ll_1203008_wmain

Типичные ошибки заказчика при работе с фрилансером

фрилансер (freelancer) — «свободный работник, частный специалист, который может одновременно выполнять заказы для разных клиентов» © Википедия. Как правило, фрилансер работает удалённо, отыскивая заказы через интернет. Занимается поиском более-менее постоянно, потому что работа имеет свойство подходить к концу. Это фактически бизнесмен — владелец фирмы из одного человека. Для многих фриланс — первая ступень к страницам Форбс (ну или они на это надеются). То есть неправильно строить взаимодействие с фрилансером по модели начальник-подчинённый.

Далее, коль скоро фрилансер — бизнесмен, выполняющий разовые заказы, он не является частью вашей команды. Заключение вроде бы очевидное, но при переговорах о нём часто забывают. Да, я прагматично работаю за деньги и не интересуюсь карьерой. Нет, я не дам вам скидку только потому, что у вашей быстрорастущей фирмы временные сложности с финансами. Тем более ничего не буду делать бесплатно. Почему? Да потому, что с одной стороны любая скидка означает меньше денег для меня и моей семьи. С другой — никаких плюсов конкретно для меня от неё не будет.

Читать дальше

Scope creep: причини і наслідки

Чи виникало у Вас коли-небудь таке відчуття, що продукт ніколи не вийде в реліз? Щоразу після зустрічі з представниками замовника з’являється потреба у новій функціональності, а обсяг робіт по існуючому функціоналу росте як на дріжджах. Як наслідок, усі початкові бюджети перевищено, а строки завершення робіт протерміновано. Знайомтесь — перед вами розростання обсягів проекту (в англомовній літературі «scope creep»).

Читать дальше

Сколько стоит создание сайта

Не существует ответа на вопрос «Сколько стоит создание сайта». Равно, также и на вопрос, сколько стоит квартира, автомобиль, свадебное платье и т.д. Стоимость одно и того же продукта, будь то «квартира», «автомобиль» или «платье» различается в несколько раз.

Однако этот вопрос заказчики постоянно задают.

Читать дальше

Какую оплату за проект лучше выбрать фрилансеру: фиксированная или почасовая ставка?

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

Так, сколько вам действительно брать с клиентов? Как понять, сколько стоит работа, чтобы ваши цены были конкурентоспособными и адекватными?

Читать дальше
3016e3bd0ba4637422e07383309cc9c9

Внедрение без ТЗ: дорога в никуда

ТОП-6 фраз клиентов

И так всё понятно — зачем тратить время?
Здесь всё просто! Да я на пальцах объясню
Почему я должен платить за то, что войдёт в следующий релиз?
Я не умею его составлять
Да программисты ничего не понимают в продажах (бизнесе, складе, бухгалтерии и т.д.)!
Вы составляете ТЗ за деньги?!
Я подразумевал другое!

Читать дальше
6de82e4fa8494d95b7184197a589b7c9

Без ТЗ: почему клиент не хочет его

«У нас очень маленький и простой проект»
«Это коммерческая тайна, мы вам не расскажем»
«Сначала скажите сколько стоит!»
«Почему мы должны платить за то, что нужно вам?»
«Мы хотим увидеть варианты!»
«А вдруг у нас изменится концепция»
«Нам нужен точный клон этого…»
«Придумайте сами — вы же специалисты!»
«Мы сами напишем/написали ТЗ»
«Другие программисты не примут ваше ТЗ»

Читать дальше

Менеджерско-программистская выжимка за 17 лет в отрасли

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

Читать дальше

«Мир есть совокупность фактов, а не вещей»: Витгенштейн и операционно-ориентированное программирование

За каждым методом бизнес-логики стоит факт мира, который этот метод (чаще не в одиночку) моделирует. Факты программирования – это операции: дальше будем называть их так. Делая метод членом класса, ООП требует от нас привязать операцию к объекту, что невозможно, потому что операция – это взаимодействие объектов (двух и более), кроме случая унарной операции, чистой рефлексии. Метод ВыдатьЗарплату (PaySalary) может быть отнесен к классам Сотрудник (Employee), Касса (Cash), БанковскийСчет (Account) – все они равнозначны в праве владения им. Дилемма о расположении методов сопутствует всему процессу разработки: неловкое ее разрешение может оказаться критичным и даже фатальным.

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

Читать дальше

6 вопросов, которые спасут проект

Недавно знакомый предприниматель поделился со мной своей бедой: «Не знаю, что делать с менеджерами проектов. Половину проектов мы делаем плохонько, а вторую половину – еще хуже. Несмотря на два десятка KPI и регулярную отчетность, они все равно не выявляют проблемы на ранних стадиях, и поэтому мы тратим вдвое больше ресурсов. Кроме того, слишком часто мы вынуждены идти на поводу у заказчиков и снижать выручку проекта. И ведь ПМ-ы – парни все хорошие и стараются, но получается все равно кое-как».

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

Так что же делать? Куда смотреть? Как понять, что в проекте уже что-то идет не так? И что именно?

Читать дальше

Класс объектов или объекты класса?

Пусть у нас есть конкретная машина. КОНКРЕТНАЯ! Не тип и не класс машин, А именно конкретная машина, на которую я указываю своим указательным пальцем. Хозяин этой машины утверждает, что его машина состоит из множества компонентов, в том числе из колес. Он говорит, что его машина состоит из пяти колес (одно запасное). Замечу сразу, что хозяин говорит: «состоит из», а не «включает в себя».

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

Читать дальше

Люди не умеют оценивать

Исследователи попросили несколько групп разработчиков дать оценку некоторых программистких задач, описанных в спецификации. В среднем, группы оценили работу в 100 часов (я пропорционально привел все данные в исследовании к круглым цифрам, чтобы было проще запоминать).

После чего, начались следующие эксперементы:

Читать дальше
dinamika

Разноцветные миры

Сколько раз с вами бывало такое: вы пытаетесь что-то объяснить человеку, но у вас не получается — он не понимает ничего из того, что вы говорите, как будто он живет в каком-то другом мире. «Да он что, с Луны свалился», — спрашиваете вы себя. Вы чувствуете, что в его мире другие законы и правила, и те же самые события трактуются совсем по-другому. Непонимание приводит к обострению отношений, создает массу негативных побочных эффектов.

Читать дальше

14 наиболее распространенных ошибок в области управления проектами

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

Читать дальше

Как не провалить ИТ-проект и остаться в рамках бюджета

Согласно исследованию компании Standish Group, затраты на ИТ-проект в среднем превышают отведенный под него бюджет на 43%. В прошлом году только 29% ИТ-проектов были выполнены в срок и в рамках бюджета, 53% проектов не были сделаны в срок или не уложились в бюджет, а 18% просто провалились.

Как не потратиться впустую
Будьте в курсе
Потеря контроля

Читать дальше