Сергей Назаренко образца 2010 года
Сергей Назаренко
образца 2010 года

Предложение о сотрудничестве

Кто я?

Я - программист по призванию. Программирую со школы (с 1991 года). За это время успел освоить множество разных языков программирования (включая несколько разновидностей ассемблера), многие из которых впоследствии пришлось забыть за ненадобностью. Также поучаствовал во множестве разных проектов (как провальных, так и успешных), некоторыми из которых даже довелось руководить.

На сегодняшний день основной моей деятельностью является разработка в среде 1С:Предприятие 8 (разработкой в 1С занимаюсь с 1997 года). Владею ею практически в совершенстве. Объекты платформы использую по назначению. Обычные и Управляемые формы (включая работу в веб-клиенте), клиент-сервеное взаимодействие, планы обмена (включая УРБД), запросы и СКД, немодальные вызовы, управляемые блокировки, подписки на события, программное управление кластером серверов 1С, веб-сервисы и XDTO-пакеты, работа в хранилище, выпуск поставок, разработка расширений, разработка мобильных приложений и многое-многое другое... Все это для меня не страшные слова, а хорошо знакомые инструменты.

Не смотря на то, что начинал я работу в 1С с версии 7.5, разработкой в версии 7.7 и ниже - не занимаюсь принципиально (это как после езды на Land Cruiser пересесть на горбатый запорожец - вроде все то же самое, но многого не хватает и жутко не удобно).

Кроме 1С, в активе у меня еще разработка на C\C++ (уверенный уровень еще со школы - с 1993 года), Java (начальный уровень) и JavaScript (начальный уровень).

Для кого я?

В первую очередь сотрудничество со мной будет интересно заказчикам, которые разрабатывают (или планируют разрабатывать) тиражные решения на платформе 1С:Предприятие 8, желают, чтобы эти решения были качественными, и понимают, что качество не может быть дешевым.

Также, я буду интересен командам, которые ведут промышленную разработку конфигураций (не обязательно тиражных) на платформе 1С:Предприятие 8, с использованием методик и технологий разработки, подразумевающих наличие стандартов и применение соответствующих инструментов.

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

А на досуге помогаю студентам с лабораторными работами (не только на 1С).

Что я предлагаю?

Я предлагаю услуги по:

Как я работаю?

Я предпочитаю строить отношения с Заказчиком на правах партнеров, опираясь на взаимное уважение и разумное доверие.
У Заказчика есть потребности. У меня есть знания, умения и навыки, чтобы ему помочь. Задача заказчика - сделать так, чтобы у меня появилось желание оказать ему помощь. Моя задача - сделать так, чтобы у Заказчика появилось желание отблагодарить меня за оказанную помощь.
"... и чтобы никто не ушел обиженным."(С)Стругацкие А. и Б.

Очевидно, что внести в задачу изменения (в том числе и исправить ошибку) на этапе постановки цели, особенно, когда она еще в голове находится - практически ничего не стоит, т.к. это можно сделать за долю секунды, просто начав думать о другой формулировке цели. А вот внести эти же изменения, но уже на этапе тестирования - стоит значительно дороже. Литература по PM (ссылку на источник, к сожалению, уже не вспомню) приводит цифры: "Стоимость исправления ошибки на этапе тестирования в среднем в 200 000 раз дороже ее исправления на этапе проектирования".
Поэтому, перед тем, как садиться что-то писать в коде, я предпочитаю сначала задавать вопросы и обсуждать задачу так долго, как будет необходимо для четкого ее понимания всеми участвующими в задаче сторонами.
Такой подход немного замедляет появление первых осязаемых результатов, зато существенно экономит средства Заказчика на получение конечного результата высокого качества.

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

Также на повышение качества результата влияют такие невидимые для Заказчика факторы, как чистота и порядок в коде (ошибки любят жить в "грязном" запутанном коде). Поэтому я, кроме того, что забочусь о соответствующем оформлении собственного кода, также, по возможности, привожу в порядок имеющийся до меня код, который мне приходится модифицировать. Такой подход увеличивает затраты на текущую выполняемую задачу, зато позволяет сильно экономить средства при дальнейшей разработке.

По поводу переключения между задачами. На семинаре одного из бывших директоров PMI Харви Левина (Harvey Levine) я узнал, что они когда-то проводили достаточно масштабное исследование разрабатывающих софт компаний, и выяснили, что компании, которые одновременно занимаются только одним проектом, на длительном промежутке времени оказываются более продуктивными (успевают успешно завершить больше проектов), чем компании, которые одновременно занимаются несколькими проектами.
Перенеся эту информацию на работу одного специалиста, я выработал для себя правило: "делать не более одной задачи одновременно". Это позволяет в долгосрочной перспективе успешно завершать большее количество задач.
Но одновременно с этим, такой подход приводит к не всегда приятному для Заказчиков эффекту - если в момент обращения Заказчика ко мне я занят какой-либо задачей, то Заказчику приходится подождать, пока я освобожусь.
Естественно, что бывают чрезвычайные ситуации, когда приходится бросать все и срочно переключаться на их устранение. Благо, что такое бывает достаточно редко.
Или бывают ситуации, что продолжение работ по текущей задаче требует ожидания какого-то внешнего события. В этом случае, чтобы не простаивать, я могу взяться за еще одну, не очень сложную задачу, помня о том, что приоритет у меня на поставленной на паузу задаче.
Но просто так бросить одну задачу и переключиться на другую - я считаю непозволительным.

Юридические моменты

Юридически я являюсь резидентом Украины, и оформлен Частным Предпринимателем (Фізична Особа - Підприємець) на Едином Налоге 3 группы, НЕ являющимся плательщиком НДС.

Принимаю оплату на расчетный счет.

Могу принять оплату как от юр. лица, так и от физ. лица.

Документальное оформление отношений

Документально оформлять взаимодействие можно разными способами.

Наиболее традиционным, надежным, но и одновременно с этим, самым неудобным способом оформления отношений, является подписание договора, и оплата по актам выполненных работ.
С примером моего типового договора "Про надання інформаційних послуг" можно ознакомиться по ссылке.
Естественно, что в каждом конкретном случае, внесение правок в договор оговаривается отдельно.
Можно обмениваться по почте бумажными копиями договора и актов, а можно и в электронном виде, подписывая их с помощью ЭЦП.

Если же подписывать договор не требуется, то возможа упрощенная форма оформления взаимодействия.

Для резидентов (граждан) Украины

Оплату можно осуществить по счету-оферте (см. пример), который можно оплатить с банковской карточки, либо в отделении любого банка Украины.

Для того, чтобы я мог выписать счет-оферту, Заказчику нужно будет заполнить небольшую анкетку (в зависимости от его правового статуса):

Для нерезидентов Украины (граждан других стран)

Оплату можно осуществить по инвойсу-оферте (см. примеры англо-украинского инвойса-оферты с физ. лицом и юр. лицом), который можно оплатить с банковской карточки, либо в отделении любого банка.

Для того, чтобы я мог заполнить инвойс-оферту, зарубежному Заказчику нужно будет заполнить небольшую анкетку (в зависимости от языка и правового статуса заказчика):

Следует заметить, что в силу того, что российские банки (я с этим столкнулся на Альфа-банке) отказываются принимать к оплате русско-украинские инвойсы-оферты в рублях, и требуют обязательной англоязычной части инвойса-оферты, а также использования доллара США в качестве валюты платежа, то для приема оплат по инвойсам-офертам от граждан РФ, я вынужден выставлять им англо-украинские инвойсы-оферты в долларах США.
Если Вам важно осуществлять оплату в рублях, попробуйте узнать в своем банке - возможно он примет к оплате русско-украинский инвойс-оферту в рублях.

Дополнительная информация

С ценами на мои услуги можно ознакомиться на странице "Цены".

Более детальную информацию о моем образовании и накопленном опыте можно получить на странице "Резюме".

Примеры моих работ можно посмотреть на странице "Дары".

Связаться со мной можно по контактам, указанным на странице "Связь".