Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 28
Устанавливайте штрафные санкции на превышение количества ошибок.
Тема не раскрыта. Кто и как будет определять за какие ошибки будут санкции? Зачем работнику идти к работодателю который может вдруг насчитать штрафов на половину зп за скажем поехавшую верстку в IE6, по штрафу за каждый уехавший блок. А что если в компании есть отдел тестирования?
Увы, но объемы статьи не дают возможность раскрыть тему полностью. Значит буду писать продолжение…
А насчет примера с IE6. Всё-таки какой-то вариант ТЗ нужен. Если в нем будет прописано, что сайт должен работать под конкретными браузерами, то вёрстка ехать не должна.
Просто профессионал тонкости знает, и в случае необходимости может сделать даже отдельную верстку для IE6. А дилетант понадеется на авось.
А насчет примера с IE6. Всё-таки какой-то вариант ТЗ нужен. Если в нем будет прописано, что сайт должен работать под конкретными браузерами, то вёрстка ехать не должна.
Просто профессионал тонкости знает, и в случае необходимости может сделать даже отдельную верстку для IE6. А дилетант понадеется на авось.
Много воды, много картинок, ожидал от статьи большего.
Вывод тоже очень и очень неоднозначный. У каждого хорошего специалиста есть свои наработки, созданные за годы кропотливой работы и размножающиеся обычно копипастом. Как быть с ними при часовой оплате труда? Не использовать и писать все заново или скопировать и получить деньги за пять минут работы?
Вывод тоже очень и очень неоднозначный. У каждого хорошего специалиста есть свои наработки, созданные за годы кропотливой работы и размножающиеся обычно копипастом. Как быть с ними при часовой оплате труда? Не использовать и писать все заново или скопировать и получить деньги за пять минут работы?
Только вчера столкнулся с ситуацией, когда тестовый набор отличается от реальных данных, пришлось фактически переписать значительный кусок программы =)
Мне кажется, что статья описывает скорее работу кодера, но не программиста.
Это, считаю, как оценивать работу художника по количеству мазков или ставить над ним камеру и учитывать только время касания холста кистью. Ну и, конечно, не оплачивать те мазки, поверх которых были сделаны другие…
С другой стороны, очень часто наблюдаю ситуацию полнейшей незаинтересованности исполнителя в реализации проекта и, как следствие, попытки потом прикрываться сознательно плохо составленным ТЗ. А сколько раз я сталкивался (в роли эксперта при приёмке) с позицией исполнителя «в ТЗ ведь не прописано, что надо проверять входные данные на корректность...» — не счесть =)
Я всегда стараюсь сесть вместе с заказчиком и постараться вместе с ним разобраться, что же всё-таки нужно получить в итоге, расписываются плюсы и минусы на перспективу и т.д. Вот тогда идёт работа на результат. Тогда же идёт и выбор инструментов для реализации, подбор используемых технологий и т.д. Ну и как бы в результате все остаются довольны.
Мне кажется, что статья описывает скорее работу кодера, но не программиста.
Это, считаю, как оценивать работу художника по количеству мазков или ставить над ним камеру и учитывать только время касания холста кистью. Ну и, конечно, не оплачивать те мазки, поверх которых были сделаны другие…
С другой стороны, очень часто наблюдаю ситуацию полнейшей незаинтересованности исполнителя в реализации проекта и, как следствие, попытки потом прикрываться сознательно плохо составленным ТЗ. А сколько раз я сталкивался (в роли эксперта при приёмке) с позицией исполнителя «в ТЗ ведь не прописано, что надо проверять входные данные на корректность...» — не счесть =)
Я всегда стараюсь сесть вместе с заказчиком и постараться вместе с ним разобраться, что же всё-таки нужно получить в итоге, расписываются плюсы и минусы на перспективу и т.д. Вот тогда идёт работа на результат. Тогда же идёт и выбор инструментов для реализации, подбор используемых технологий и т.д. Ну и как бы в результате все остаются довольны.
Зачастую компании стараются не нанимать девушек, которые недавно вышли замуж. Считается, что они собираются завести ребенка, что компании в общем-то не сулит ничего хорошего…
И девушки часто получают необоснованные и немотивированные отказы. Одна моя знакомая придумала и написала некое «обязательство» не заводить детей в течение двух лет (это была ее инициатива, не работодателя).
Эта бумажка не имела никакой законной силы. Но работу после этого она получила.
Так же и с заказчиками. Есть множество причин, чтобы платить исполнителю за время, затраченное на проект. Но заказчики боятся это делать. Вот эти страхи и их преодоление я и постарался описать.
А методы убеждения заказчиков могут быть разными. Давайте подумаем какие еще бывают (кроме убеждения :) )
И девушки часто получают необоснованные и немотивированные отказы. Одна моя знакомая придумала и написала некое «обязательство» не заводить детей в течение двух лет (это была ее инициатива, не работодателя).
Эта бумажка не имела никакой законной силы. Но работу после этого она получила.
Так же и с заказчиками. Есть множество причин, чтобы платить исполнителю за время, затраченное на проект. Но заказчики боятся это делать. Вот эти страхи и их преодоление я и постарался описать.
А методы убеждения заказчиков могут быть разными. Давайте подумаем какие еще бывают (кроме убеждения :) )
Во-первых, считаю, главный метод — это честность. Очень много потенциальных заказчиков обожглись как раз на нечестном исполнении, после чего выбрали позицию «лучше купить готовый продукт, чем что-либо заказать».
Мне как-то один исполнитель очень долго доказывал, что система оповещения по электронной почте (вставить в функцию логов несколько строк для отправки уведомления в случае появления критических ошибок) из Java-приложения — это титанический труд, который как минимум удвоит стоимость и учетверит объем работы. Пришлось немного процитировать RFC (если просто на сокетах писать), ну либо предложил воспользоваться имеющимся в Java классом. Исполнитель негодовал.
Часто исполнители нагло пользуются незнанием заказчика. Это не хорошо. При чём это касается не только нашей отрасли, менталитет у нас что-ли такой: кинь ближнего своего, ибо не ведает он…
Мне как-то один исполнитель очень долго доказывал, что система оповещения по электронной почте (вставить в функцию логов несколько строк для отправки уведомления в случае появления критических ошибок) из Java-приложения — это титанический труд, который как минимум удвоит стоимость и учетверит объем работы. Пришлось немного процитировать RFC (если просто на сокетах писать), ну либо предложил воспользоваться имеющимся в Java классом. Исполнитель негодовал.
Часто исполнители нагло пользуются незнанием заказчика. Это не хорошо. При чём это касается не только нашей отрасли, менталитет у нас что-ли такой: кинь ближнего своего, ибо не ведает он…
«в ТЗ ведь не прописано, что надо проверять входные данные на корректность...» — не счесть =)
Если я не эксперт в предметной области, то без спецификаций мы ногу сделать хорошие тесты, да и не понятно корректные эти данные или нет. Поэтому получаются ситуации:
когда тестовый набор отличается от реальных данных, пришлось фактически переписать значительный кусок программы
Оооо… Вы слишком глубоко копаете, предметная область, спецификация… =)
Элементарный пример — поле, в которое должна быть введена цифра, например, целочисленное поле «кол-во»… Очепятываемся и, в зависимости от кучи факторов, получаем от нефатальной ошибки, до фатального вылета без сохранения =(
У нас в крае такая милая программа для сдачи данных в ПФР ходила (или до сих пор ходит): одна очепятка и фатал эррор с потерей данных. Хотя, судя по внешним признакам, можно было бы хотя бы в блок try… обернуть
Элементарный пример — поле, в которое должна быть введена цифра, например, целочисленное поле «кол-во»… Очепятываемся и, в зависимости от кучи факторов, получаем от нефатальной ошибки, до фатального вылета без сохранения =(
У нас в крае такая милая программа для сдачи данных в ПФР ходила (или до сих пор ходит): одна очепятка и фатал эррор с потерей данных. Хотя, судя по внешним признакам, можно было бы хотя бы в блок try… обернуть
А кстати, как в таких случаях правильно? Допустим, есть поле для суммы в рублях и кто-то вбил туда 110ю00. Как обрабатывать такую ошибку?
1, попап «неправильно введена сумма», красный флажок у поля, пустое поле
2. попап «неправильно введена сумма», красный флажок у поля, старые данные в поле- «110ю00»
3. попап «исправлена опечатка», красный флажок и пустой чекбокс «проверено» у поля, в поле «110 руб. 00 коп.»
4. крэшиться и запускать ракеты
5. иначе
1, попап «неправильно введена сумма», красный флажок у поля, пустое поле
2. попап «неправильно введена сумма», красный флажок у поля, старые данные в поле- «110ю00»
3. попап «исправлена опечатка», красный флажок и пустой чекбокс «проверено» у поля, в поле «110 руб. 00 коп.»
4. крэшиться и запускать ракеты
5. иначе
Коллега, прямо на холивар провоцируете.
Считаю, что «правильность» реакции зависит от конкретной ситуации, используемого языка, окружения и т.д.
Если мы говорим про обычное прикладное ПО, то от себя могу сказать, что считаю п.4 неправильным, если иное не оговорено ТЗ. Во всех остальных случаях исключительная ситуация должна быть обработана и, как минимум, не должна приводить к потере/искажению данных.
Считаю, что «правильность» реакции зависит от конкретной ситуации, используемого языка, окружения и т.д.
Если мы говорим про обычное прикладное ПО, то от себя могу сказать, что считаю п.4 неправильным, если иное не оговорено ТЗ. Во всех остальных случаях исключительная ситуация должна быть обработана и, как минимум, не должна приводить к потере/искажению данных.
Вопрос холиварный, но у меня совсем плохо с UI. Я понимаю, что нужно без потери данных известить пользователя, что что-то не так, но стоит ли додумывать за него, если это прямо не указано в ТЗ?
Додумывать (что именно сделать в случае ошибки) — по желанию.
Обрабатывать исключения, не давая обрушить систему — обязательно.
ИМХО, конечно.
Обрабатывать исключения, не давая обрушить систему — обязательно.
ИМХО, конечно.
Я бы никогда не додумывал, во всяком случае в ситуациях когда нет единственно верного толкования действий пользователя. Стоит учитывать что у всех людей разные привычки по использованию софта и вводу данных и то что вам может казаться логичным и удобным для кого-то может оказаться раздражающим и стать причиной отказа от продукта. Лично я достаточно часто ма... выражаюсь нецензурно из-за автокомплитов не к месту.
>>А сколько раз я сталкивался (в роли эксперта при приёмке) с позицией исполнителя «в ТЗ ведь не прописано, что надо проверять входные данные на корректность...» — не счесть =)
В данном случае заказчик сам себе злобный буратино.
В данном случае заказчик сам себе злобный буратино.
«в ТЗ ведь не прописано, что надо проверять входные данные на корректность...»
А бывает и такое — с заказчиком проговоришь, что они будут отдавать данные только в таком виде и проверяешь их на корректность. И тут раз — засада — данные в другом виде.
Как должен выглядеть мониторинг, если исполнитель покинул рабочее место (не совершает никаких телодвижений по написанию кода в течении 3-х часов) и отправился гулять вокруг здания, обдумывая сложное место? Или предполагается что все сложные в реализации места проработаны и согласованы до начала работ?
А это уже по договоренности с заказчиком. Если он готов оплачивать время обдумывания, то без проблем.
В смысле «готов оплачивать время обдумывания»??? Нам платят именно за то, что мы думаем. Хочется больше строк кода — пускай берут машинистку, у неё это лучше получается.
Это — самая проблемная часть всех контролей. Если есть хорошее и подробное ТЗ — то можно по нему просто писать код и замерять время написания. Но это работает в простых случаях.
А если надо написать нечто, о чем у всех очень смутное ощущение (у заказчика нет необходимых технических знаний, чтобы продумать, как все должно работать) — то много времени уйдет на придумывание алгоритма, а само написание кода займет относительно мало времени.
А если надо написать нечто, о чем у всех очень смутное ощущение (у заказчика нет необходимых технических знаний, чтобы продумать, как все должно работать) — то много времени уйдет на придумывание алгоритма, а само написание кода займет относительно мало времени.
В этом случае выходом могло бы стать именно написание ТЗ самим исполнителем с повременной оплатой. А дальше точная оценка времени и работа за фиксированную сумму.
И как проконтролировать, что исполнитель именно ТЗ пишет? :)
Иногда, чтобы написать пару абзацев, надо неделю ковыряться в задаче… И при этом ты ведь часто ничего, что может увидеть (проконтролировать) посторонний, не делаешь. Рисуешь что-то на доске — как другой человек поймет, это ты пытаешься структуру данных набросать, или имитируешь деятельность?
Иногда, чтобы написать пару абзацев, надо неделю ковыряться в задаче… И при этом ты ведь часто ничего, что может увидеть (проконтролировать) посторонний, не делаешь. Рисуешь что-то на доске — как другой человек поймет, это ты пытаешься структуру данных набросать, или имитируешь деятельность?
Тогда надо секундомер. Как пошел пописить, то сразу выключил секундомер.
Либо с заказчиком заранее обговорить, как будет оплачиваться время на пописить
Либо с заказчиком заранее обговорить, как будет оплачиваться время на пописить
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Время — деньги, или аргументы за и против почасовой оплаты