Хочу поделиться мыслями как бы это могло быть сейчас, если бы я столкнулась с этим проектом не 10+ лет назад, а сейчас.

Мой внутренний кэп говорит, что поступить нужно было так:

Внимательно выслушать Михаила, записать детали беседы.

Попросить у него содействия и контакты сотрудников турбазы, дабы ознакомиться с их версией того, как же это всё на самом деле работает: весь процесс от поступления заявки на аренду домика и лодки до выезда посетителей с турбазы.

Обязательно выйти на контакт с бухгалтерией!

Разделить работу на понятные обеим сторонам этапы (с оплатой этапов 🤑).

Обязательно обозначить что входит в первый этап (на бумаге! Под подпись обеих сторон, как приложение к договору!) - в нашем примере это как раз и были бы домики да лодка. Но! Мы бы понимали, что система может быть сложнее и заранее бы заложили возможность её масштабирования. А не переписывали бы по 10 раз одно и то же с появлением новых вводных данных.

Обязательно начать работу с системой после реализации первого этапа. Обозначить это изначально. Выведение продукта в продакшн должно быть! И если бы заказчик отказался от остальных этапов, для нас, компании-разработчика, это был бы не проект-провал, а завершенный проект. При желании / возможности заказчик вернётся и можно продолжить. А не то, что получилось у нас..

Что по поводу продажи получившегося решения.
Конечно, в идеале, это нужно закладывать заранее. Так как коробка сильно отличается от продукта под заказчика. Но если идея пришла "опосля".. Как минимум нужно понять и отделить фишечки от работающей схемы. Если тратиться на анализ не хочется - включить в пакет "решение" часы программиста, в рамках которых программист допилит нюансы.  А уж если покупатель захочет большего - подписывать  договор обслуживания или работы по стандартному тарифу.

И конечно правило "Клиент всегда прав" не работает в условиях проекта. Мы обязаны соблюдать правила, не рушить концепцию и не забивать на логику. Ведь представьте, что было бы, если бы хирург опирался на принцип безусловной правоты клиента? 😨😨 Пациенту ещё жить. А нашей программе работать в сложных условиях 😅

Одна тысяча и 24 бита

Быть IT-шником - просто сказка 😊

"Правильно ли я Вас понял, что..", - фраза, которая должна быть задана заказчику перед началом каких-то изменений, даже если они кажутся логичными, правильными, своевременными, технологичными и прочее.

Почему?

Как бы мы, разработчики, ни старались быть на одной волне с заказчиком, сколько бы ни вникали в логику бизнес-процессов, и даже если у нас есть отличный друг - аналитик, который всегда готов приземлить нас плашмя на землю фразой: "Стопэ.. Послушай, на самом деле всё не совсем так..", - Многое остаётся за рамками обсуждения и понимания.

Ситуэйшн.

В учётной программе есть жёстко регламентируемый и контролируемый список сотрудников - менеджеров. Заказчик неоднократно акцентировал внимание, на то что список этот очень важен для учёта. Разработчик сделал всё, что просил заказчик и решил ещё дополнительно облегчить труд заказчика: сделал обработку, которая, в случае если сотрудника назначили на должность менеджера, он, сотрудник, автоматически включался в этот регламентированный список... 💥

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

Во время разбора полётов разработчик очень удивился. Ну ведь это же менеджер! Значит логично, что он должен быть в этом списке!

"Правильно ли я Вас понял, что.." + "если сотрудника назначили на должность менеджера, его нужно включить в этот список? ", - вопрос, который не был задан перед началом разработки. Зато появилась дополнительная нагрузка в виде чистки лишних действий в алгоритме, проверки состава утверждённого списка сотрудников и удаления оттуда лишнего, написания письма с объяснением, какого фига у нас программа своей жизнью живёт..

#истории

Одна тысяча и 24 бита

Быть IT-шником - просто сказка 😊

🎄Чем ближе конец года тем сильнее сжимается удавка на шее 1С программиста: отчётность, новые релизы (бедолаг из фирмы 1С определённо приковали к батарее и выдают еду только за новый выпущенный релиз. Иначе никак не могу обосновать скорость и частоту выпуска чего-то "новенького"), старт новых проектов, продление сроков старых🐸..

Но, предлагаю сделать минутную паузу и поздравить друг друга с Наступающим Новым Годом!

Мы выжили 🥂

Делитесь как проходят ваши последние рабочие часы этого года? Много ли планов на новый? Как вообще настрой? 😎

Воин: Клянусь честью, что жестоко отомщу за смерть брата!
Эльф: С тобой будет мой лук!
Гном: И мой топор!
Некромант: И ТВОЙ БРАТ
...

Выполняю план на сегодня

Вспомнить кто я?
Кем работала в 2023?
За что это всё мне?

Конечно я утрирую. Любимые пользователи не дадут забыть о себе даже на НГ праздниках. Также в первую очередь меня ждут релизы, которые старательно выпускали 29 и 30 декабря голодные 1С разработчики, в надежде, что им дадут понюхать бутерброд.

С Наступившим! И с началом первой официальной рабочей недели🥳

Всё самое интересное только начинается 👍

Из чатика планеролюбов стащила прекрасное 😉

Я с корабля на бал, можно сказать, уже почта завалена требованиями "срочно подключиться".

 "Я тут что-то хотел, но забыл. Ты подумай, какая тут проблема.. ", - Разработчики о процессе разработки.

Очень часто в ИТ проектах от документации отказываются по причине того что реалии меняются на столько быстро, что эта самая документация устаревает ещё до того как её написали и утвердили...

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

И вот тут-то 100-тысячный раз собирается совещание, где подписывается меморандум о намерении вести эту самую никому не нужную документацию, ибо даже анализ кода не даёт полного понимания что хотел пользователь, как реализовал разработчик и вообще нужно ли это кому-нибудь.... А в это время в отделе ИТ разрывается телефон от вопросов "У нас новый сотрудник вышел. Вы должны подготовить рабочее место и выслать инструкции. Он приступает к работе вчера".

Особый юмор это когда ИТ разделён на отделы. Например: программисты, системные администраторы, консультанты (первая линия). И  у каждого участника этой истории, включая конечного пользователя, своё представление с чем он имеет дело, как это должно работать и где искать инструкции... 🤯

Сейчас, в эпоху массовой автоматизации, компании пытаются передать полномочия ознакомления пользователя с инструкциями алгоритмам рассылки.. Но и для этого нужна документация.. Я вот, впервые познакомившись с подобными механизмами будучи пользователем, получила в рассылке многостраничный документ, данные которого меня вообще не касались. Сначала я подумала, что это тест на сообразительность 😅 и честно пыталась вникнуть в суть написанного 😂
Спасибо, что конфиденциальную информацию не прислали🤡

И вот вроде бы всё понятно: инструкции и документация нужны.. Но вопрос как найти баланс трудозатрат между поддержанием этой писанины и ведением разработки остаётся открытым. Ведь даже наличие технического писателя в штате не отменяет необходимости разработчику формулировать устно или письменно что он там наразрабатывал 🤷‍♀️

Начало года заставило меня встрепенуться шумным грохотом выпавшего скелета с дальней полки шкафа под названием сервис деск 🤯
В прошлом году я знатно навозилась с задачей по переводу программы и даже оставила кое какие заметки тут

Но суета оперативных задач затолкала эту работу на дальний план.

Могу сказать, что перелопатить пришлось тонны информации, так как ранее такого опыта не имела. Большой пласт работы оказался бесполезным😭. Много глюков и багов. Но сейчас могу сказать, что проект почти готов: сейчас занимаюсь наполнением переведёнными значениями уже непосредственно данных справочников в режиме предприятия.

Так как в интернет вопросов по подобным задачам много, а информации маловато, поделюсь своим опытом здесь.

Постановка задачи. Конфигурация Документооборот 3 (не мультиязычная версия). Нужно обеспечить работу программы в режиме сербского и русского интерфейса и представление данных на сербском и на русском языках.

Я уже упоминала, что большой пласт работ оказался бесполезным. Это получилось из-за скорее моей собственной невнимательности😓. Я, опираясь на документацию и изучая программный код, видела, что в конфигурации есть (как мне казалось) зачатки блока перевода. Но, зная, что есть отдельное платное решение для работы на русском и английском языках, не найдя упоминания о возможности использования нескольких языков в текущей программе, сделала вывод, что нужно реализовать своё. И реализовала. Но, моё решение начало конфликтовать с механизмами самой конфигурации. И тут я поняла, что фактически Документооборот 3 имеет полноценный функционал для ведения данных на трех языках (один из которых русский). Для его активации достаточно нежно поработать дамской пилочкой для ногтей. Спасибо ленивым разработчикам, за почти идентичную конфу с другим платным решением 😊

Что ж.. Бесполезную работу сохранила. Когда-нибудь пригодится 😂

Перевод интерфейса сделала посредством механизма "Редактирование текстов интерфейса". И именно эту часть хочу описать подробнее в формате препятствий и банановой кожуры, на которых я набила немало синяков..

Как я уже писала в предыдущем посте на тему перевода, придётся повозиться с форматами ковычек, пробелами, пропажами символов, если вы будете пользоваться переводчиком. Это ручная работа.

Перевод всё же лучше сделать переводом файла, а не гугл таблицы - это быстрее и меньше проблем с пропажей символов.

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

Не выгружать на перевод бизнес процессы. Формы можно. Но данные схем, модулей - нет.
Я столкнулась с вылетом платформы при попытке загрузить переведённый текст. Учитывая, что на вход шло порядка 75 тысяч строк.. Я долго искала причину вылетов.. 😵

Самый важный вопрос. А что с обновлением?
Так вышло, что как раз вышел новый релиз программы, и я, выполнив перевод всего и вся, решила проверить его установку. На удивление всё прошло отлично! Выполнив стандартное обновление, я сделала повторную загрузку файла  с переводом в режиме "Только незаполненные". Да, есть вероятность, что появятся новые фразы, которых в файле нет. В моем случае этого не произошло. Но, если такие обнаружатся, можно их перевести отдельно, за рамками огромного файла. Ведь мы можем выбирать, какие объекты пойдут на анализ механизма Редактирование текстов.

Сейчас, видя изобилие всплывающих подсказок-пузырьков, затухающие сообщения в правом нижнем углу и прочие бантики и премудрости управляемых форм, активно использующиеся в Документооборот 3, могу сказать, что считаю верным решением перевести именно саму конфигурацию, а не тащить перевод "на лету" из регистра при открытии формы. Потому что у меня все эти пузырьки теперь могут говорить как на русском так и на сербском языке.🎉
#1С

Женщина - ИТ-шник явление распространённое, но по-прежнему не повседневное.  К женщинам - программистам/аналитикам вроде бы привыкли, но женщина - системный администратор это нонсенс, хотя мне посчастливилось познакомиться с женщиной - сисадмином ) отличный специалист между прочим!
Но в глазах всё ещё большого круга людей ИТ-шник это прежде всего мужчина. А зря.

Ада Лавлейс
Грейс Хоппер
Карен Спарк
Лоис Хайбт
Радия Перлман

И многие многие многие другие специалисты-женщины внесли и вносят огромный вклад в общее ИТ-шное дело.

Наши преимущества? Легко:
💃
За один проход приготовить завтрак, отвести ребёнка в садик, сделать маникюр, зайти в 5 магазинов, порадовать себя шоколадкой🍫, - оптимизация это к нам)

Ошибка🔠 - ерунда. Припудрила, подрумянила и ошибка стала фичей🦋, - вывод в продакшн тоже к нам.

В спешке на важную деловую встречу повредила чулки... Капелька лака для ногтей 💅и ты снова в строю,- гибкость и нестандартный подход тоже про нас.

Ну а факт, что на моем факультете программирования и администрирования из 40 человек было 5  мальчиков.. говорит сам за себя.

Женщин в ИТ сфере много и это круто!

А чего это я тут вдруг про женщин?
Думаю вы уже догадались.

8 Марта же на носу.

С чем поздравляю всех! 🌷

Уйдя отдыхать 7-го марта, очнулась вечером 24 апреля) хорошо хоть в рамках одного года.

Если без шуток, год начался бодро и темпы не сбавляет.

За это время произошло много интересностей:
🔸 пробую себя в роли код ревьювера на курсе 1С разработчик.
🔸 проект Документооборот 3 на сербско-русском языке вошёл в активную фазу. Много планов на развитие, в том числе за пределы просто оборота документов.
🔸запланирован проект по внедрению программы ЗУП в локализации для Узбекистана - вливаюсь
🔸 решились таки развивать вики - портал с инструкциями, ибо вот это шутка про инструкции становится уже не шуткой, а печалью.
🔸 медленно, но двигаюсь в своём обучении на data scientist.
🔸 ну и, конечно, текущие инциденты и вопросы никуда не деваются😅 куда же без любимых пользователей.
🔸 пытаюсь включить капельку физ. активности дабы не принять форму кресла 😂 нагрузка нужна не только умственная, да да.

Пунктиков получилось много. Впечатлений от всего этого море. Багов, фишек, просто наблюдений и размышлений ещё больше. Есть о чём рассказать.

Так что.. Продолжение следует ❤️ спасибо за то, что читаете и поддерживаете комментариями и смайликами 🌷

😅 Поделился со мной товарищ картинкой

Да, тут нам, программистам, не повезло. Заказчики искренне верят, что вся наша работа какая-то "недоделанная", ведь всегда есть новые пожелания и способы улучшения. А раз есть, значит недоделано и точка.

Если к дому решили сделать пристройку или построить рядом гараж, можно ли сказать, что дом был недостроен?

Я думаю, что считать что вся работа недоделана в корне неверно: это полная демотивация и лишняя тяга к шоколадкам, кофе, сигарете. 

Как бороться?

Для себя стараюсь придерживаться следующего:

📎Отделять эмоции заказчика от требований к задаче
📎Делить задачу на подзадачи
📎По завершению этапа "ставить галочку" о выполнении (даже если это не нужно заказчику, делать это для себя)
📎Завершение глобальной задачи можно отметить шоколадкой 😊

С другой стороны.. Много незавершенных задач формирует большой список "жути", который не позволит нагрузить программиста ещё чем-нибудь. Тоже своего рода польза 😅

Часто сталкиваетесь с бесконечными задачами? Спасаетесь или используете во благо?

Ну что ж.. Вернулась я к своему курсу дата сатаниста сайентиста в части изучения блока по программированию на python в режиме:

"🤬 как закончить за полгода курс, рассчитанный на год с учётом малого количества свободного времени😱".

А задачки с каждым модулем растут от "привет мир" до "а напишите-ка калькулятор и вспомните оператор xor" 🤯 
Как говорил мой преподаватель алгебры : "Плохо когда забыл.. да ещё и не знаешь".

Хотя самой большой сложностью я бы назвала привыкание к английской раскладке после 15 лет кодинга на русском 🤣
Эту проблему ни один поисковик не решит🤷‍♀️