Автор Nuxt.JS вперше в Україні на конференції JavaScript fwdays | 14 березня, Київ
×Закрыть
  • Как добиться взаимопонимания с клиентом: 5 простых правил

    лучше бы он их знать не знал

    А что изменится если пытаться что-то объяснять клиенту? Експертизы у него как не было так и нет. Проверить ваши слова он не может. решения принимает все ещё клиент. И он все ещё хочет верить в то что хочет верить.

    Не стоит отказываться от каких-либо действий убедив себя заведомо в «не разрешат» и «не получится» =)

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

  • Как добиться взаимопонимания с клиентом: 5 простых правил

    Ту надо ставить вопрос ’кто принимает решения и насколько принимающий решения компетентен ?’ можно ещё добавить ’кто будет нести ответственность’. Если расклады таковы, что решения принимает клиент, при этом он не компетентен в области, но платит деньги и несёт ответственность, то все вопросы отпадают. Нет смысла ему что-либо объяснять про ’неработающие штуки’.
    А вот если часть ответственности на исполнителях, то тут все сложно. Тут или предлагать только заранее годные варианты, и так чтобы клиент выбирал только из них. Самодеятельность не позволять. Ну или сразу оговаривать — на ком ответственность тот и принимает решения

  • Как добиться взаимопонимания с клиентом: 5 простых правил

    Ну, во-первых донести что ’такой-то тул не подходит для решения такой-то задачи’ это уже сложно. Во-вторых, вариант с накидать на коленке альтернативу вообще-то не работает. И это даже хуже чем рандомный выбор кастомера.
    Потому что для начала надо сформулировать задачу (ее как правило нет сформулированной на этом этапе).
    Потом определиться с критериями выбора тулов/фреймворков/языков/технологий. Это уже долго. А потом надо ещё и проевальюировать пол рынка, чтобы найти хотя бы первый годный тул.
    На коленке такое не делается. Штатного времени на такое тоже как правило не дают.
    А вариант предложить на коленке альтернативу — он местами хуже варианта кастомера. Как минимум потому что ,на свой собственный вариант кастомер уже был согласен

  • Как добиться взаимопонимания с клиентом: 5 простых правил

    Оттого что вы расскажете клиенту, что текущий стек технологий/языки/либки/фреймворки не способны решить ту задачу, которую поставили — ничего особо не поменяется.
    Не редкость когда выбор фреймворка это что-то вроде ’ а у наших конкурентов именно этот фреймворк, мы его тоже возьмём’.
    И никакие аргументы не работают.
    Более того, если спросить напрямую а почему выбрали именно этот тул — то это вгоняет клиента в ступор. Это мы ещё даже не начали говорить про критерии выбора.
    Кстати, менее компетентных левов никто не отменял. Они все ещё придут и объявят неработающую штуку работающей.
    Иногда в роли таких девов сам клиент. И тогда вообще зашибись

  • Почему стоит включить в разработку прототипирование

    А что именно вы пытаетесь решить такого рода прототипами? Зачем они ? Для кого ?
    Судя по рисункам это не MVP. И это уж точно не прототип UI от дизайнеров.
    Это и не прототип дизайна/архитектуры системы. Потому как в нем отсутствуют структурные связи (целостная картина). Тем более что в разработке этого прототипа отсутствовал техлид.
    Если это был прототип требований от заказчика, то он ИМХО содержит много лишней информации (визуальной), и даже вводит в заблуждение...что из этого требование , а что просто часть прототипа/заглушки

    Поддержал: Сергей Сахно
  • Как добиться взаимопонимания с клиентом: 5 простых правил

    С пунктом 1 ( про impossible ) все далеко не так однозначно. Не редко бывает что приходит клиент и ставит некую задачу. Тим лид или команда садятся и начинают Брейн шторм. И по ходу дела оказывается что в постановке задачи есть противоречия. Или что у каких-то штук есть зависимости и нельзя просто так взять и подкрутить чтобы обе были с некоторыми характеристиками , а можно только 1. Или что некоторые вещи в принципе невозможны в неких условиях (используем не real time OS, а хотим строгие гарантии по времени отклика)
    На этой все лид /дев прямо скажет impossible.
    А потом к клиенту приходит кучка менее компетентных девов, и гордо объявляют неработающую штуку работающей. И клиент им верит, потому что ему очень хочется верить. А проверить он не может....

  • Портрет ІТ-спеціаліста — 2019. Інфографіка

    Лего картинки это конечно забавно. Но лучше б отдали raw данные. И графичками. А то выборка параметров для написания текста отчета как-то не очень.
    Даёшь raw!

  • «Метод наводчика» при работе с пул реквестами

    Поинт в том, что по сути нужно не пост фактум ревью сделанного кода, а ревью решения/дизайна Перед началом имплементации.
    И да, это будет микро agile.

  • «Метод наводчика» при работе с пул реквестами

    Есть один интересный нюанс.
    В схема с 2мя исполнителями получается скорее ’дизайн ревью’. Ревью неких решений, архитектурных и не только. То есть из пост фактум ревью пулл реквестов мы так плавно перешли к ревью дизайна Перед началом исполнения.
    Это действительно полезно. Вот только собственно сам пулл реквест теперь ревьювить не очень надо. Потому что если что-то пойдет не так, то принимающий опять будет ревьювить дизайн. И потом снова имплементация. И так по кругу.

  • Меньше, но лучше: как повысить качество кода

    А что за метрики production-а такие?
    Интересно как вы меряете что приложение действительно работает у пользователя.

  • Почему я против тестов на собеседованиях для IT-специалистов. Взгляд рекрутера

    А что есть рекрутеры, которые действиткльно обладают навыками для оценки soft skills? Если да, то это что-то новенькое.
    Обычно там не оценка, а описание каких-то ощущений рекрутера. Обратное чрезвычайно редко.
    А насчёт Codility и ему подобных. Ни рекрутер, ни менеджер во многих случаях понятия не имеют что действительно надо будет делать на проекте. Могут даже лидов не спросить. Описание вакансии пишут как-нибудь . В итоге найти надо универсального единорога.
    Вот и прилетают всякие тесты.
    Не то, чтобы от них нет пользы. Просто они как правило не релевантны с реальной вакансией.
    Бесит именно то что они не релевантны.

  • Программист разумный

    Вообще-то для embedded очень даже характерна задача добиться размера бинаря не больше чем Х. А размер бинаря это один из видов метрик для измерения сложности. Так что...

  • Программист разумный

    Т.е. есть как минимум 3 разных понятия, подразумеваемых под ’сложность’. Но нет, будем смешивать их в одно потому что есть 1 слово?
    Теперь про пресловутую ’общественно полезность’ и ’трудоемкость’.
    Трудоемкость можно выразить через количество логических операций необходимых для решения задачи. Оно очень даже осязаемое и измеряемое. Причем консистентно от человека к человека. Другой вопрос что для некоторых подзадач существуют уже готовые решения, и некоторые об этом знают, а некоторые нет.

  • Программист разумный

    Будет ли измеренная сложность объективной действительно зависит от метрики. И тем не менее, если иметь дело только с обективно измеряемыми параметрами, то и измеренную таким образом сложность тоже можно назвать объективной.
    Не ’истинной ’ или ’правдивой’. А всего-лишь объективной

  • Программист разумный

    Не работает для чего?

  • Программист разумный

    И ничего там толком ты не найдешь. Будут безумные фантазии психолухов

    Видимо вы никогда, или почти никогда не читали нормальные papers. Papers, а не высеры в интернетах . Иначе бы не утверждали что там нет определений. Или что это фантазии.

    Оценка экпертов на то и оценка, что это оценочные суждения. И в некоторых случаях оценка базируется на объективных показателях/метриках.

    И нет, такой подход скорее не работает чем работает. (оценка сама по себе)
    Более того, оценка експертом скорее всего нужна для достижение консенсуса по некоторому вопросу.

  • Программист разумный

    Работает. Прямо с ходу могу назвать аж несколько вариантов. Знаю проекты где это применяется.
    — все та же цикломатическая сложность
    — тупо размер бинаря
    — наличие и количество циклов переменной длинны (очень актуально для всех real time систем)
    — все та же О(N)

    И все это про ’сложность’

    Поддержал: Ruslan Dmytrakovych
  • Программист разумный

    А с каких пор цикломатическая сложность стала фиктивной метрикой?
    А ’сложность в человеческом понимании’ это про оценочные суждения. Они как правило субъективны. И естественно не консистентны от человека к человеку.
    Если покопаться, то в каких ни будь paper по психологии найдется даже определение этой ’сложности’.
    Так вот собственно, объективная сложность системы (измеренная какой-нибудь метрикой) != субъективная оценочная сложность.

  • Программист разумный

    И цикломатическая сложность не единственная метрика сложности системы.
    Можно например представить систему графом, и считать количество ребер (связей) в нем. Тоже метрика сложности.

  • Программист разумный

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

    А то ’сложность’ которое про оценочное суждение человека, для него есть другие слова. Да вот хотя бы ’оценочная сложность’.

← Сtrl 12 Ctrl →