Конкретно там — поставили девайс, отображающий содержимое экрана охране и пишущий его циклически неделю. Но это для того, чтобы не воровали и не обсчитывали клиентов. С чеками добавили специальные отчёты для начальства по сомнительным операциям и аннулированным чеками.
Не пробил чек — такого не бывает. Это как раз решается программно. Нет чека — нет дальнейшей работы. Более того, формально, по-другому и работать нельзя.
вопрос с воровством решается правильной отчётностью :) А если заказчик не может или не хочет наводить порядок со своими сотрудниками — то очертить зону ответственности. Я же не Мать Тереза, чтобы все его проблемы решать :) Моё дело предупредить.
А с чеками махинаций много бывает. Самая простая — не отдавать чек, если не просят и давать потом клиентам чек на бОльшую сумму. Можно начинать бить чек, а потом сразу аннулировать его — все законно, а клиента остаётся нормальный чек (нет последней строки в чеке, но это редко кто замечает).
Иногда вообще бьют нормальный чек и оформляют продажу, а затем делают отмену продажи и бьют чек возврата. У клиента остаётся совершенно нормальный чек. Нужно, конечно, заносить в журнал и писать объяснения, но это себя окупает.
Да, это было специально. И бесплатно. Это не требовало много сил. Несколько раз встретиться с заказчиком. Почитать его предложения. Изложить свои. Если какие-то силы и тратятся, то моральные. Зато растёт коммуникативный скил и налаживаются отношения с потенциальным работодателем. По времени это тоже не затратно. Максимум — сесть прикинуть возможности и варианты, а это в любом случае нужно делать. Параллельно можно работать над чем-то ещё.
По второму пункту не совсем понял. Можно сказать это и были «лучшие практики», так как предлагаемое (и сделанное) значительно отличалось от того к чему привык персонал. Но так как пожелания персонала выслушивались, вносились некоторые изменения, да, и вообще, много времени тратилось на обучение, то всё всегда проходило гладко. Как я написал оптимальный путь — найти толковых людей и обучить их. Заодно обкатать способы обучения и внедрения. Обученных, затем привлекать к процессу обучения остальных. Были случаи явного саботажа (причина — в результате автоматизации, как правило, усиливается контроль и перекрываются возможности дял всяческих махинаций) в таких случаях действовал через начальство. Иногда приходилось идти по цепочке вверх (непосредственное начальство оказывало «повязанным» со своими подчинёнными), до тех пор пока не находил человека, заинтересованного в улаживании конфликта. Иногда приходилось уговаривать начальство не наказывать подчинённых. Короче говоря лично я считаю, что нужно налаживать отношения с коллективом, но без панибратства и в случае конфликтов не бояться обсуждать их с заказчиком. Был очень показательный пример. Там, где есть кассовая техника (особенно на заправках) иногда обильно процветает мухлёж с кассовыми чеками. Мухлёжь совершенно безобидный для клиентов и практически законный. Более того, он даже несколько поднимает пристиж и привлекательность организации. Начальство ничего об этом не знало. После внедрения нового софта мухлёжь стал не возможен. Начался тихий саботаж со стороны работников. Пришлось долго и нудно разбираться пока понял, что проблема создаётся специально и в чём истинная её суть. Дальше пошёл к начальству изложил суть вопроса. Первой реакцией заказчика было «Всех уволю!». Пришлось вступиться за сотрудников и объяснить, что возможно имеет смысл не запрещать, а взять под контроль. Сошлись на том, что была добавлена ограниченная возможность для мухлежа и новые отчёты. Заказчик провёл воспитательную беседу с подчинёнными и указал рамки в которых он будет закрывать глаза. Это сильно оздоровило коллектив и сняло проблему. Правда, месяца через три ему всё таки пришлось показательно уволить двух человек.
Да там сплошные сложности — сложный и захватывающий процесс! :) И сложности возникали и продолжают возникают каждый раз :) Как их избегать я вроде рассказал — работать с заказчиком, смотреть, что на самом деле побудило его к этому заказу, смотреть на задачу со всех сторон :)
да такое бывает. Тут нужно думать.
В идеале — по-моему, правильное решение — сказать заказчику, что данная доработка выходит за рамки изначально оговоренного проекта и требует значительных доработок и может быть сделана за дополнительную плату.
На практике иногда приходится срочно переделывать, чтобы ублажить заказчика, но он от этого иногда наглеет :)
Запускаться же нужно однозначно без «хотелок/забывалок». Иначе придётся долго доказывать, что не верблюд и до внесения изменений «мамой клянусь всё работало». Дорабатывать уже после запуска. Это поднимает авторитет в глазах клиента.
А я, вот, даже отвечу :) Ну, наверное какая-то работа у меня есть. Возможно она меня чем-то не устраивает? И наверное я действительно без труда найду работу. Проблемм в том, что я уже вырос из того возраста и состояния, когда можно сидеть и бездумно лабать что-то перед монитором и хочется найти интересную (или!) высокооплачиваемую работу.
Именно для этого есть этапы макета и тестовой эксплуатации. У заказчика есть последний шанс что-то добавить/изменить. Иногда, если я предвижу подобное развитие событий, я специально ввожу этап тестовой эксплуатации, пишу «сырую» версию с базовым функционалом и настаиваю на том, чтобы заказчик с ней поработал. И даже притормаживаю разработку на некоторое время. То есть даю заказчику возможность окончательно определиться со своими запросами.
Ну, прежде всего это был далеко не первый мой подобный проект и цены я приблизительно знал. Но конкретно тот проект оценивал сугубо из здравого смысла — желаемая зарплата помноженная на время работы. В некотором роде продешевил, но, во-первых, заказчик остался счастлив, а, во-вторых, реальная трудоёмкость и загрузка были далеко не 100% — после установки пробной версии работать приходилось лишь время от времени :)
Сдаётся, слышу я ехидство в Вашем тоне… 11 лет и несколько десятков проектов пойдёт? Кому интересно — без проблем найдут мое резюме. И я категорически отказываюсь флудить по этому поводу.
Ах да, интересное замечание — в качестве сервера баз данный был выбран Interbase (firefox). Т.к. по личным наблюдения только он может пять лет работать без обслуживания на офисном компьютере, который даже выключают иногда прямо пилотом, и не нарушить целостность базы. Всё остальное или стоило много денег, или (как например MySQL и иже с ним) не обеспечивало надёжности и отказоустойчивости.
Такой опыт тоже есть. Хотя и меньший. Как негативный так и позитивный.
Главное — чёткое разделение ролей и субординация.
С заказчиком должен общаться один человек. Если есть необходимость чтобы общались несколько, то должно быть чёткое разграничение области компетенции. В любом случае любые обещания должен давать и согласовывать один человек — нарушение этого правила погубило несколько проектов.
Обязательно должен быть человек с правом решающего голоса. Так как иногда на ровном месте возникают споры по пустяку — должен быть однозначный способ разрешения таких ситуаций.
Возможно, когда-нибудь, изложу негативный и очень поучительный опыт работы в команде :)
Пол года. Три месяца до рабочего макета. Ещё два месяца до финальной версии и месяц — на доводку. Писалось в свободное время.
Использовался Delphi. Ибо позволяет достичь максимального результата за минимальные сроки при минимальном уродовании. В будущем буду использоваться Java. C++ — слишком трудоёмко, негибко и не удобно для визуализации. .Net на тот момент была тёмной лошадкой со странными перспективами.
Да, но в данном случае человек выступает, как сотрудник организации. А автор топика не давал этой организации гарантий о неразглашении. Хотя я считаю, что в данном случае публиковать имя действительно не правильно — это может быть политика компании, а человеку будет подпорчена репутация.
Обратите внимание — они не сообщают пользователю об эвристике и не говорят «возможно». Они утверждают, что там вирус и препятствуют использованию и распространению программы. Это уже упущенная выгода, недобросовестная конкуренция и т.п.
Почитайте в интернете :) Лениво лекции по технике безопасности читать. Могу сказать, что запрещено ГОСТами. В некоторых случаях, допускается при наличии УЗО, но с любом случае это менее надёжно и более опасно.
Фигачит потому, что импульсные блоки питания (в компьютере, например) обязательно имеют связь корпуса с фазой через небольшую ёмкость. Если этого не делать, то они начинают со страшной сильной шуметь и глушить радиоприборы. Соответственно на корпусе образуется неслабое напряжение. Убить такое может только тех, у кого проблемы с сердцем. И горят мониторы/принтеры/сетевые карты/мат. платы при соединении при включённом компьютере именно по этой причине.
Не пробил чек — такого не бывает. Это как раз решается программно. Нет чека — нет дальнейшей работы. Более того, формально, по-другому и работать нельзя.
А с чеками махинаций много бывает. Самая простая — не отдавать чек, если не просят и давать потом клиентам чек на бОльшую сумму. Можно начинать бить чек, а потом сразу аннулировать его — все законно, а клиента остаётся нормальный чек (нет последней строки в чеке, но это редко кто замечает).
Иногда вообще бьют нормальный чек и оформляют продажу, а затем делают отмену продажи и бьют чек возврата. У клиента остаётся совершенно нормальный чек. Нужно, конечно, заносить в журнал и писать объяснения, но это себя окупает.
По второму пункту не совсем понял. Можно сказать это и были «лучшие практики», так как предлагаемое (и сделанное) значительно отличалось от того к чему привык персонал. Но так как пожелания персонала выслушивались, вносились некоторые изменения, да, и вообще, много времени тратилось на обучение, то всё всегда проходило гладко. Как я написал оптимальный путь — найти толковых людей и обучить их. Заодно обкатать способы обучения и внедрения. Обученных, затем привлекать к процессу обучения остальных. Были случаи явного саботажа (причина — в результате автоматизации, как правило, усиливается контроль и перекрываются возможности дял всяческих махинаций) в таких случаях действовал через начальство. Иногда приходилось идти по цепочке вверх (непосредственное начальство оказывало «повязанным» со своими подчинёнными), до тех пор пока не находил человека, заинтересованного в улаживании конфликта. Иногда приходилось уговаривать начальство не наказывать подчинённых. Короче говоря лично я считаю, что нужно налаживать отношения с коллективом, но без панибратства и в случае конфликтов не бояться обсуждать их с заказчиком. Был очень показательный пример. Там, где есть кассовая техника (особенно на заправках) иногда обильно процветает мухлёж с кассовыми чеками. Мухлёжь совершенно безобидный для клиентов и практически законный. Более того, он даже несколько поднимает пристиж и привлекательность организации. Начальство ничего об этом не знало. После внедрения нового софта мухлёжь стал не возможен. Начался тихий саботаж со стороны работников. Пришлось долго и нудно разбираться пока понял, что проблема создаётся специально и в чём истинная её суть. Дальше пошёл к начальству изложил суть вопроса. Первой реакцией заказчика было «Всех уволю!». Пришлось вступиться за сотрудников и объяснить, что возможно имеет смысл не запрещать, а взять под контроль. Сошлись на том, что была добавлена ограниченная возможность для мухлежа и новые отчёты. Заказчик провёл воспитательную беседу с подчинёнными и указал рамки в которых он будет закрывать глаза. Это сильно оздоровило коллектив и сняло проблему. Правда, месяца через три ему всё таки пришлось показательно уволить двух человек.
В идеале — по-моему, правильное решение — сказать заказчику, что данная доработка выходит за рамки изначально оговоренного проекта и требует значительных доработок и может быть сделана за дополнительную плату.
На практике иногда приходится срочно переделывать, чтобы ублажить заказчика, но он от этого иногда наглеет :)
Запускаться же нужно однозначно без «хотелок/забывалок». Иначе придётся долго доказывать, что не верблюд и до внесения изменений «мамой клянусь всё работало». Дорабатывать уже после запуска. Это поднимает авторитет в глазах клиента.
Главное — чёткое разделение ролей и субординация.
С заказчиком должен общаться один человек. Если есть необходимость чтобы общались несколько, то должно быть чёткое разграничение области компетенции. В любом случае любые обещания должен давать и согласовывать один человек — нарушение этого правила погубило несколько проектов.
Обязательно должен быть человек с правом решающего голоса. Так как иногда на ровном месте возникают споры по пустяку — должен быть однозначный способ разрешения таких ситуаций.
Возможно, когда-нибудь, изложу негативный и очень поучительный опыт работы в команде :)
Использовался Delphi. Ибо позволяет достичь максимального результата за минимальные сроки при минимальном уродовании. В будущем буду использоваться Java. C++ — слишком трудоёмко, негибко и не удобно для визуализации. .Net на тот момент была тёмной лошадкой со странными перспективами.