작성중인 문서입니다.
기획
해커톤 수상의 40%는 기획력, 40%는 발표력이라고 봐도 무방하다. 발표 또한 탄탄한 기획을 바탕으로 하기 때문에, 해커톤에 있어 가장 중요한 단계이다. 개발 시작 시간이 늦어지더라도 아이템 발굴 및 구체화가 중요하다.
브레인스토밍
해커톤의 주최 기관, 심사위원, 주제 등 다양한 요인에 의해서 아이템이 달라질 수 있지만, 신박하지 않더라도 신박하게 풀어내면 되는 것이기 때문에,
아이템 정하기
사용자 수 * 사용기간
예상되는 사용자 수와, 해당 서비스를 사용할 것으로 생각되는 시간의 곱을 판단하여, 가장
목적을 잃지 말라
기획 구체화를 하다 보면 최초 기획의 목적을 잃고 샛길로 새는 경우가 허다하다. 목적을 잊지 말고 구체화에 임하여야 하고, 샛길로 샜을 때 그 기획이 더 좋다면, 기획의 Title을 수정하여야 한다.
정말로 해결해야 되는 문제가 맞는가
특정 제도나 서비스에 종속적이지 말라
해당 제도나 서비스에 변화가 생기면 그 아이템은 쓸모없어진다.
설문조사 또는 논문의 수치 자료를 활용하자
서비스의 특성을 명확하게 인지하자
서비스를 바라보는 개인적인 관점으로는 다음과 같은 기준이 있다. 어떤 것이 좋고 나쁘고는 없다.
- 컨텐츠를 제공해야되는가 / 컨텐츠가 생성이 되는가
생각중입니다
개발
최대한 코드작성을 피하자
짧은 기간 내에 보여줄 수 있는 것을 최대한 많이 끌어내야 한다. 클린코드, 테스트코드, CI/CD는 과감히 배제하고, 로직 코어 개발에 몰두하는 것이 낫다. 또, 로직쪽 코드를 집중하여 보다 보면, 획기적인 추가 기능이 떠오르기도 한다.
백엔드의 로직코드를 최대한 프론트엔드로 올리자
백/프론트 시스템을 구축하려면, 네트워킹 시스템이 필요하다. 백/프론트를 제대로 구축하고 운영하려고 했던 팀들은 오히려 완성도가 떨어지는 모습을 보였다. 그 시간에 프론트 디자인에 힘을 쏟는 것이 더 완성도가 높아 보인다.
로그인 및 회원관리 기능은 최대한 제거하자
두 사용자 이상 인터랙션이 필요하다거나, 관리자/사용자와 같이 여러 계층의 사용자가 존재하는 서비스가 아니라면 개발시간을 앗아가는 로그인 및 회원관리, 토큰 관리 등의 기능은 최대한 제거하는 것이 좋다. 로그인이 필요하다더라도, boilerplate가 있어서 바로 도입이 가능한 상황이 아니라면 id 정보로만 로그인할 수 있도록 간략하게 구현하자
발표
부정적인 표현을 하지 않는다.
자랑하기 바쁜 발표시간이다.
목차를 스포일러하지 않는다.
면접과는 다른 느낌이다. 두괄식이 아닌, 어그로로를 끌고 흐름을 끌어내야된다.
