alk

Подскажите, что это за стек технологий?

По опыту своих коллег:
Потрындеть по 4 часа в день друг с другом, час пить чай/кофе, ещё час материть заказчиков и последний час чтобы написать пару строчек кода.

Дело скорее не в стеке технологий, а в том, что 2 большие разницы работать в команде в офисе и работать дома фрилансером. Как минимум атмосфера разнится, а по факту - процесс разработки построен иначе. Как вариант - кадровики не хотят связываться с человеком, который "попробует, ему не понравится в офисе" и он свалит обратно во фриланс.

Чтобы перестать делать лучше то, что ещё не сделано до конца, нужно понять одну простую истину: Запущенный проект лучше, чем не запущенный.

Давайте потренируемся:

• Что лучше: запущенный проект с несжатыми стилями или незапущенный со сжатыми?
  
• Что лучше: не запущенный проект с десятью страницами или запущенный с тремя?
  
• Что лучше: запущенный проект c jQuery или не запущенный без jQuery?
  

Надеюсь, вы смогли выбрать! Как узнать, что пора запустить проект? (Под запуском я имею в виду «показать людям». Например, если вы решили написать библиотеку, давайте считать «проект запущенным», если вы выложили её на гитхаб) Нужно прикинуть, сколько времени вам надо на разработку и умножить на два. Если получилось больше двух недель, то стоит разбить проект на части и прикинуть так про каждую часть. Соответственно, ставите дедлайны.

Промежуточные дедлайны помогают успеть к последнему. Старайтесь сначала реализовать основную функциональность, а потом дополнительную. Если не успеете к дедлайну доделать дополнительное — сначала запустите основное, а потом видно будет, надо ли вообще доделывать дополнительное.

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

Удачи!

Не зная софта тяжело сказать что и как требуется. Но обычно:
1. Гарантийные обязательства обычно включают в себя:
- Указание срока его предоставления.
- Исправление критических ошибок
- Консультирование клиента в рамках функционирования ПО (отдельно можно описать круг тем).
- Обновлении версий
- Функционирование ПО в рамках обязательств заключенных в договоре (или приложении ТЗ к нему) или указанных в акте (или иных договоренностей) на момент сдачи ПО.
- Иное обслуживание ранее указанное в договоре/акте/... на момент сдачи ПО. Например, Вы договорились что у клиента ориентировочно через 3 мес откроется пару филиалов и Вы настроете ПО на работу с ним.

2. Поддержка может включать в себя обычно: техническое обслуживание, аварийное обслуживание, обучение.

2.1 Аварийное обслуживание. Заранее прописывают 2 вещи: категорию аварии и время реагирования/время устранения + штрафы(не обязательно финансовые, может быть разрыв договора) в случаи нарушения. Например,
1я категория - не запускается софт (например из-за установки service pack на ОС) время реагирования=30 минут, время устранения=3 часа.
3я категория - криво сформировался ежегодный отчет (в следствие нарушения данных и т.п.) . Время реагирования=1 час, время устранения=5 раб. дней.

2.2 Техническое обслуживание. Обычно тут "хотелки" (написать небольшой дополнительный функционал, например, добавить ИТОГО,графики + доп колонки в какой-либо отчет) либо доп. требования (например, выгрузка каких-либо данных для налоговой из инет-магазина при изменении законодательства). В договоре опять-же категоризируют такие работы (например: установка дополнительного АРМ, экспорт-импорт данных в XML/JSON/TXT в стороннее ПО ...) и устанавливают доп цены на них принципу:
N штук таких работ выставляют в виде периодической абонплаты, а выше N - по отдельной цене (например, за фиксированную почасовую оплату). Будет хорошо, если вы приложите расценки с указаниям кол-ва часов для решения наиболее возникающих проблем. Также указывают штрафы при нарушении сроков и т.п.

2.3. Обучение. Обычно после сдачи софта разработчик берется:
- Обучить N сотрудников работе с ним в течении X дней.
- При изменении версии (или критическом обновлении) произвести обучении M сотрудникам в течении Y дней.
- Периодически проводить семинары для Z сотрудников не реже S дней в квартал
Все что за пределами этого (и не входит в гарантийные обязательства) - прописывается и категоризируется. Отдельно прописываются права третьих лиц за отдельные виды работ (например, возможность нанимать внештатных инженеров).

Также совет - попросите у знакомых (лучше работающих в иностранных конторах) анонимайзированные (персональные и юр/фин данные забиты ИВан Иванычами и *) договоров продажи ПО с прописанными SLA, приложениями (категории и виды доп работа, бланки-заказов, актов и т.п. - сразу станет понятнее.

Берете например 1-3% от стоимости ПО и вводите как плату за поддержку.
От вас нужны быстрые багфиксы критических ошибок и обычные багфиксы в обычном рабочем режиме. Хотя по идее это вы должны делать бесплатно по договору в котором указаны гарантийные обязательства в течении некоторого срока.
Еще нужны выезды к клиенту для решения вопросов на месте.
Вам может позвонить админ в 3 ночи и спросить почему все упало или как запустить это ПО

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