Идея проверять расчет зарплаты - не бессмысленна. Пример не совсем корректный.
В некоторых организациях допиливают разные параметры, характерные для узкой специализации конкретного бизнеса. Эти доработки вкручивают в типовые расчеты и считают зарплату своим сотрудникам уже с учетом этих параметров.
И как раз после таких доработок появляются ошибки в учете. Так почему бы не проверять функционал автоматически, тестировать по сценариям? Функционал знает аналитик - он писал ТЗ, архитектор - он строил архитектуру решения, программист - он этот функционал писал, методист/РП - он пишет руководство по настройке и работе с этим функционалом.
Об этом функционале не знают в 1С, нет типового или даже отраслевого решения, т.к. по каким-то причинам бизнес решил изобрести велосипед или автоматизировать собственные, нетиповые процессы, но они влияют на расчет заработной платы.
ИМХО, смысл в тестировании, считаю, есть, но пример не совсем корректный. Нужен пример какого-то нетипового механизма, который работает в связке с расчетом зарплаты.
В ответ на вероятные нападки на "недружелюбный" интерфейс 1С могу заметить, что "красивый" интерфейс не даст профит, если процессы незрелые. От этого они не повзрослеют.
Но работу существенно облегчат, из-за интеграции с учёными системами, сотрудниками и т.п.
Что подразумевается под переработкой?) Если программист не успевает выполнить задачу днем, в рабочее время, то имеет полное право заниматься ею в выходные, если это идейный программист, если он горит желанием развиваться и решать проблемы. Причины "неуспевания" в рабочее время: мало ли что могло случиться - сервер навернулся внезапно, интернет отключился, сеть барахлит, народу в офисе много (если опен спейс), дети бесятся (если на удаленке и есть дети), кошка с ума сходит и мешает работать (если на удаленке и нет детей, но есть кошка)...
ИМХО, я не считаю такие моменты переработками. Даже когда работаю в выходные по задаче/проекту, я все равно развиваюсь. Ведь почему я не смог решить ее в рабочее время? Потому что не хватает компетенций.
В рабочее время у меня его свободного не так много, могут быть ограничения на интернет-ресурсы в целях кибербезопасности, зато на выходных я могу свободно обратиться к интернету и прочитать/посмотреть/найти нужную мне информацию, и может быть даже к ПН закончить какой-то этап.
Мы, когда задача готова процентов на 50, устраиваем с заказчиком встречу, очно или созвон, чтобы показать ему результат проделанной работы и сориентировать по срокам готовности. А когда реализуем большой проект, в котором задействованы несколько пользователей, причём из разных отделов, мы набираем "тестовую команду" и, буквально, отдаём на тест в копии базы, чтобы они сами понажимали кнопки, чтобы сами поняли свои процессы, и только если ошибок нет, тогда выгружаем доработки в рабочую базу.
Information
Rating
Does not participate
Location
Москва, Москва и Московская обл., Россия
Date of birth
Registered
Activity
Specialization
Программист 1С, Руководитель направления внутренних проектов 1С
Идея проверять расчет зарплаты - не бессмысленна. Пример не совсем корректный.
В некоторых организациях допиливают разные параметры, характерные для узкой специализации конкретного бизнеса. Эти доработки вкручивают в типовые расчеты и считают зарплату своим сотрудникам уже с учетом этих параметров.
И как раз после таких доработок появляются ошибки в учете. Так почему бы не проверять функционал автоматически, тестировать по сценариям?
Функционал знает аналитик - он писал ТЗ, архитектор - он строил архитектуру решения, программист - он этот функционал писал, методист/РП - он пишет руководство по настройке и работе с этим функционалом.
Об этом функционале не знают в 1С, нет типового или даже отраслевого решения, т.к. по каким-то причинам бизнес решил изобрести велосипед или автоматизировать собственные, нетиповые процессы, но они влияют на расчет заработной платы.
ИМХО, смысл в тестировании, считаю, есть, но пример не совсем корректный. Нужен пример какого-то нетипового механизма, который работает в связке с расчетом зарплаты.
Прикольно, но описывает две крайности.
В России ввели прогрессивную шкалу НДФЛ
В ответ на вероятные нападки на "недружелюбный" интерфейс 1С могу заметить, что "красивый" интерфейс не даст профит, если процессы незрелые. От этого они не повзрослеют.
Но работу существенно облегчат, из-за интеграции с учёными системами, сотрудниками и т.п.
Варианты: kaiten, yougile, самописная конфигурация 1С, интегрированная с 1С: БП
Можно потом создать сборник статей - "Неудержимые. Russian release" 🤣🤣🤣
Техлид и архитектор это одно и то же?
Что подразумевается под переработкой?)
Если программист не успевает выполнить задачу днем, в рабочее время, то имеет полное право заниматься ею в выходные, если это идейный программист, если он горит желанием развиваться и решать проблемы.
Причины "неуспевания" в рабочее время: мало ли что могло случиться - сервер навернулся внезапно, интернет отключился, сеть барахлит, народу в офисе много (если опен спейс), дети бесятся (если на удаленке и есть дети), кошка с ума сходит и мешает работать (если на удаленке и нет детей, но есть кошка)...
ИМХО, я не считаю такие моменты переработками. Даже когда работаю в выходные по задаче/проекту, я все равно развиваюсь. Ведь почему я не смог решить ее в рабочее время? Потому что не хватает компетенций.
В рабочее время у меня его свободного не так много, могут быть ограничения на интернет-ресурсы в целях кибербезопасности, зато на выходных я могу свободно обратиться к интернету и прочитать/посмотреть/найти нужную мне информацию, и может быть даже к ПН закончить какой-то этап.
Поэтому, что считать переработкой?
Мы, когда задача готова процентов на 50, устраиваем с заказчиком встречу, очно или созвон, чтобы показать ему результат проделанной работы и сориентировать по срокам готовности. А когда реализуем большой проект, в котором задействованы несколько пользователей, причём из разных отделов, мы набираем "тестовую команду" и, буквально, отдаём на тест в копии базы, чтобы они сами понажимали кнопки, чтобы сами поняли свои процессы, и только если ошибок нет, тогда выгружаем доработки в рабочую базу.