Как изменить программу создатель

Зачем вообще может потребоваться смена разработчика мобильного приложения? Как правило, по одной или нескольким причинам:

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

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

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

IPHONE vs XIAOMI

Что не так с передачей дел в мобильной разработке

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

Мобильная разработка, да и вообще IT-проекты, отличаются высочайшей зависимостью заказчика от подрядчика.

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

Несостоятельная.

Например, у вас есть согласованное ТЗ (техническое задание), текущие результаты разработки на ваш взгляд не соответствуют, сроки вышли. Значит можно требовать… чего конкретно?

• От доработки по ТЗ подрядчик может и не отказываться. Просто он выставляет дополнительные счета, что обосновывает в терминах, которые непонятны ни вам, ни суду.
• Возмещать убытки вроде как не за что. Работа же выполнена. А ее качество, опять же, требует технологических и прочих экспертиз. Кто и как будет выносить такие оценки, принимать или нет их к сведению — двойная лотерея.
• Хорошо, просто передайте все материалы по проекту, чтобы закончить его с другим IT-подрядчиком. О, вот тут начинается самое интересное!

Все что вам должны «передать» как раз и определяет качество выполнения IT-проекта. Можно даже сказать, что когда подрядчик способен и готов выполнить все требования по передаче проекта в полном объеме — нет никакой разумной причины менять его на другую компанию.

Поскольку тут много разных аспектов, их можно упрощенно классифицировать по аналогии с авто-страховками:

Топ 5 ПРОФЕССИОНАЛЬНЫХ программ для МОНТАЖА ВИДЕО на Андроид!

• ОСАГО, то есть обязательный минимум.
• КАСКО. Разумные дополнения.
• VIP-тариф. Нечто вроде «покрытия» с полным восстановлением разбитой машины, здоровья всем участникам и свидетелям ДТП, а также их личной жизни, хорошего настроения и веры в чудеса.

Два ключевых слова: код и доступы.

Собственно, исходный код это и есть то самое мобильное приложение, которое вы заказали. Логично, что код должен быть у вас (заказчика) и в конечном счете его не должно остаться у разработчика (подрядчика).

Впрочем, полное отчуждение исходного кода в реальной жизни невозможно. Вы не сможете проверить и доказать, что опыт разработки в рамках вашего заказа используется на других проектах. Скорее всего, ваши конкуренты смогут получить те самые «лучшие отраслевые практики», о которых так любят говорить при продаже IT-решений. Ладно, это неизбежное зло. Вы тоже получили все лучшее, чему разработчик научился на предыдущих проектах.

Тут важно по крайней мере получить полную копию кода своего приложения — выгрузку архивом или ссылкой на репозитории вроде GitHub или GitLab.

Крайне желательно привлечь еще одного внешнего подрядчика, который оценит наличие, комплектность и качество кода.

Более того, чтобы избежать проблем, нужно проводить аудиты кода регулярно. Как минимум перед каждой очередной оплатой. Каждый раз, когда вы оплатили разработчику этап работы и подписали промежуточный акт сдачи-приемки, у вас должен оставаться готовый, проверенный, устраивающий вас код в полном объеме.

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

Далее, нужно получить ВСЕ необходимые и возможные доступы, имеющие отношение к проекту. Например (но не только эти):

• Домен
• Битрикс
• Платежные сервисы
• Аккаунты разработчиков
• Сторонние сервисы

Везде должны быть указаны ваши контакты — юрлицо, почта, телефон. Все, что оформляется юридически, изначально нужно оформить на себя. Никаким «удобством» нельзя оправдать то, что ваш ресурс вам по сути не принадлежит.

Если сомневаетесь в важности этого пункта, посмотрите художественный, но весьма познавательный фильм «Социальная сеть». В нем рассказывается о том, как один из учредителей небезызвестного Facebook был аккуратно вытеснен из числа выгодополучателей. При оформлении прав на мобильное приложение картина технически и юридически немного другая, но в целом все происходит именно так. Либо вы полностью контролируете происходящее, либо вас вообще нет в схеме.

Дальше мы погружаемся в пучину мечтательных хотелок. К сожалению, на обычных проектах не получится требовать ничего дополнительного. Основное бы получить. Однако по-хорошему нужно еще хотя бы три вещи:

• Документация
• Changelog
• Bagtracker

Давайте по порядку. Слово «документация» звучит понятно, особенно по контрасту с другими терминами. Но это обманчивое ощущение. Вам нужны исчерпывающие руководства администратора системы, программистов, баз данных, пользователей. Каждое из них детализируется в тома технических описаний. Из них должно быть ясно:

• Как перезагружать систему
• Где находятся конфигурационные файлы
• Какие IP и доступы используются
• Как выглядит админская часть, что в ней можно и чего нельзя делать
• Все про базы данных (версии, скрипты создания, бэкапы)
• Где софт «крутится» физически, какие там настройки
• IDE, зависимости, библиотеки, фреймворки

С каждым последующим уточнением все становится не более, а менее понятным. Вам опять нужен внешний аудитор. Точнее, он пригодился БЫ в том случае, если разработчик действительно предоставит полный пакет документации. Но скорее всего этого не произойдет. Что очень жаль, ведь отрывочные описания алгоритмов мало говорят о реализации.

Значит, потом будут проблемы.

Changelog описывает последовательность разработки. Что и как меняли, в какой очередности, с какими результатами. Полная картина о ходе проекта, по которой другой разработчик сможет быстро включиться в работу и продолжить развитие продукта. Мог БЫ это сделать, получи он настоящий changelog. Но скорее всего, этого не будет.

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

Допустим, ваш подрядчик оказался «The One», почти как Нео из «Матрицы». Он предоставил код, доступы, документацию, историю разработки и тестирования. Здесь уже стоит дважды подумать, на кого и зачем вы собрались его поменять.

Но возможно этот вопрос не обсуждается. Например, не сошлись по знакам Зодиака. Хорошо, тогда остается еще один последний рывок.

На экране сектор «Приз». Все самое лучшее, чего только можно было ожидать от подрядчика и проекта. Тут можно много нафантазировать, но для счастья достаточно трех главных пунктов:

• ТЗ в идеальном порядке. Со всеми правками и дополнениями.
• Wiki проекта. Внутренняя база данных — не приложения, а самой разработки.
• CustDev, технология и документация бесшовных обновлений без остановки сервисов.

Снова зовите внешнего аудитора, если он еще не живет в вашем офисе. Нужно инспектировать ТЗ с момента первого согласования, а потом по каждому изменению. «Немного подправить» это «частное техническое задание» (ЧТЗ). Оно отдельно разрабатывается, проверяется на согласованность с прежним планом и ресурсным обеспечением, потом интегрируется в проект и запускается на выполнение. Если так не делать, вы никогда ничего не докажете. Не только в суде, а вообще.

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

Наконец, на вершине пищевой цепочки разработки с точки зрения интересов заказчика находится CustDev. Это технология, которая служит гарантией качества — только не в моменте, что гораздо проще и почти бесполезно. А в динамике, с учетом всех изменений, доработок, обнаруженных ошибок, их исправлений.

Все эти вопросы стоит задавать себе и подрядчику еще до запуска проекта. До подписания контракта с ним. Чтобы синхронизировать ожидания, проверить подходы к ведению разработки и предотвратить проблемы в будущем.

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

Мораль простая: не надейтесь «приструнить» разработчика при необходимости. Вы не сможете этого сделать, просто потеряете время и деньги. Заменить его тоже будет очень сложно, потому что передать новому подрядчику часто буквально нечего.

Сразу выбирайте такого IT-партнера, который обещает сделать все правильно. И обязательно проверяйте его действия с помощью компетентного внешнего аудитора.

Профилактика лучше лечения. Это любой врач подтвердит.

Показать ещё
2 комментария

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

Развернуть ветку

Отличная статья, заметил что проблемами с сменой разработчиков страдают в основном в проектах за фикс, где подписывается ТЗ и берется аванс 50%.

Лучше работать по ТМ, расчитываться раз в месяц, сделать возможным завершение договора по инициативе любой из сторон (либо по какой-то причине, либо с предупреждением за месяц). Если разрабы тупят, то вы потеряете максимум месяц работы (а не полгода).

При этом надо сократить цикл обратной связи, настроить CI/CD и демо-стенд, который видит заказчик.

Аудитор это мастхэв, практикуем это с клиентами. Многие студии боятся пускать к себе такого аудитора, но это на самом деле решает кучу проблем с доверием. Главное чтобы аудитор не микроменеджил и не вмешивался в активный процесс

Я бы еще добавил, что аудитор должен смотреть на maintainability, архитектуру и кодстайл. Попросите студию врубить линтер кода в пайплайн и проверять кодстайл автоматически. Документацию можно и нужно генерить автоматически, это тоже защитит вас, когда разрабы начнут сливаться/тупить

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

Источник: vc.ru

Как поменять автора в Word? (Решение)

Всем привет! Когда вы работаете и создаете документ, ему приписывается несколько свойств. Одним из них является имя и инициалы автора. По умолчанию значение автора берется от «Пользователя» Windows, под которым вы сейчас сидите. Проблема в том, что частенько вместо реальных имени или фамилии туда записывается первое слово почтового ящика, на которого зарегистрирована учетная запись Microsoft.

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

Способ 1: Параметры всех документов

В этой главе мы поменяем настройки автора в самой программе Word. Таким образом в будущем при создании новых документов у них будет предустановлен тот автор, которого вы установите в параметрах программы.

1. Откройте Microsoft Word.

1. В левом блоке найдите «Параметры» и перейдите туда.

1. В разделе «Общие» найдите подраздел «Личная настройка Microsoft Office». В строке «Имя пользователя» укажите то имя, которое будет в свойствах документа во всех новых файлах. Также вы можете ниже указать «Инициалы», если они нужны. В конце обязательно примените параметры, нажав по кнопке «ОК».

Способ 2: Изменение имени в уже существующем документе

В этом способе я покажу вам, как изменить автора в уже сохраненном файле. Например, вы хотите наоборот убрать или удалить информацию о том, кем был изменен документ Word.

1. Перейдите в раздел «Файл».

1. Во вкладке «Сведения» нажмите «Свойства» – «Дополнительные свойства».

1. Теперь измените «Автора» и сохраните параметры, нажав левой кнопкой мыши «ОК».

Способ 3: Удаление всей информации о документе

В этом варианте я покажу вам, как полностью убрать автора в Word.

1. Кликните правой кнопкой мыши по уже существующему файлику и зайдите в «Свойства».

1. На вкладке «Подробно» нажмите по ссылке «Удаление свойств и личной информации».

1. Установите переключатель в режим «Удалить следующие свойства для этого файла». Далее поставьте галочки напротив той информации, которую вы хотите убрать.

Вроде мы рассмотрели все возможные варианты. Дорогие и любимые наши читатели. Если я что-то упустил или не написал, у вас есть вопрос или какая-то нерешенная проблема – смело обращайтесь в комментарии. Мы со специалистами портала WiFiGiD.RU обязательно постараемся вам помочь. Только старайтесь писать максимально подробно, чтобы мы смогли вас понять.

Источник: wifigid.ru

Как в Компас 3D изменить данные в основной надписи?

Как менять заблокированные поля штампа, такие как «Разработчик», «Проверил» с уже занесенными фамилиями. Фамилии не стираются обычным способом.

комментировать
в избранное
Simpl­ e Ein [202K]
5 лет назад

У вас появилась необходимость изменить стандартные поля штампа по своему усмотрению? Сделать это обычным редактированием основной надписи нельзя.

Для редактирования полей основной надписи необходимо выбрать на Стандартный панели меню Сервис.

В ниспадающем меню выбрать Библиотека стилей. далее Основные надписи, как показано на рисунке.

В открывшемся окне необходимо выбрать: чертеж. констр. первый лист (см. рисунок).

В данном окне можно редактировать штамп чертежа. Для этого необходимо нажать на кнопку Редактировать.

Теперь можно приступать к редактированию.

автор вопроса выбрал этот ответ лучшим
комментировать
в избранное ссылка отблагодарить
2 года назад

Тем, кто с программой Компас мало работал, может показаться, что разобраться в ней сложно. На самом деле, это не совсем так. Программу можно освоить.

Для изменения данных в основной надписи нужно зайти во вкладку «Настройка», далее «Библиотека стилей», где и находится «Основные надписи».

Всплывёт окошко для редактирования остюновной надписи, жмём на значок карандаша. Откроется новое окно, жмём на «Редактировать».

Приступайте к редактированию основной надписи, по завершению нажмите на кнопку «Перечитать».

Надпись изменится и внесённые изменения будут отображаться в поле штампа, в основной надписи.

комментировать
в избранное ссылка отблагодарить
Laliq­ ue [53.7K]
3 года назад

В программе Компас-3D v18, для того, чтобы стереть фамилии разработчика, проверяющего, и другие данные — необходимо сначала понять, как они появились в штампе чертежа.

Для начала выбираем вкладку на верхней панели чертежа «Настройка» — «Библиотека стилей» — «Основные надписи»:

Дальше появляется окно, где мы находим свое оформление документа и нажимаем на карандаш, что значит «Редактировать»:

Дальше мы видим окошко, где можем менять штамп чертежа, и еще различную информацию. Но нас интересует «Основная надпись» (именно там и расположены фамилии разработчика и проверяющего). Также здесь можно добавить в штамп наименование либо логотип предприятия. Нажимаем «Редактировать»:

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

Важный момент! Если после всех этих манипуляций основная надпись чертежа не меняется, то совершите такое действие:

1. Зайдите в дерево построения чертежа, там нажмите правой клавишей мыши на оформление вашего листа.

1. Нажмите на кнопку «Перечитать».

комментировать
в избранное ссылка отблагодарить
Yurah­ aU [106K]
5 лет назад

В программе «Компас 3D» большое количество всевозможных разных рамок, а также основных надписей. И иной раз появляется необходимость изменить стандартные надписи («Разработчик», например). Однако сделать это не просто, так как программа блокирует всякие попытки внести изменения в эти надписи.

Но такая возможность всё же имеется!

Для этого откройте вкладку «Сервис», затем «Библиотеки стилей, типов. «, и здесь выберете «Основные надписи».

В открывшемся окне «Работа с основными надписями» необходимо из списка выбрать основную надпись, которую вы хотите изменить. Затем кликайте по ней два раза левой кнопкой мыши, в результате чего откроется «Основная надпись». Здесь в первую очередь необходимо изменить «Имя», а «Номер» нужно делать больше 100, дабы новая запись не записалась вместо существующей. Далее нужно выбрать участок в котором заменяем текст «Состав основной записи», просто нажмите на «Редактировать».

Источник: www.bolshoyvopros.ru